- Inkscape Devel - Inkscape Mailman

New PreviewHolder and swatches dialog design.
by Tomasz Boczkowski 28 May '14

28 May '14

Hi! I have designed a new class layout for PreviewHolder. It's functionality is illustrated at [1] Because the new widget should support not only rendering paints, but also glyphs and symbols, a flexible architecture is needed. I've choosen MVC approach, heavily based on Qt MV model design [2]. It is shown at [3]. In the upper part of the picture there are generic model and view classes. The lower part shows the application in swatches dialog. Model is organized as a hierarchy of lists. Qt documentation explains similar hierarchy of grids [4]. It enables navigating and iterating through the structure and defined signals when items are inserted, moved or deleted. Model class itself does not contain data (classes that inherit it do) and it's methods do not provide access to data items. Model index is array index generalization for hierarchical structures. PreviewHolder belongs to the "View" part. It is the widget that displays items categories and places the preview tiles. To make things work it needs a model and a means to display (and access) model data. The latter is provided by TileRenderers. TileRenderers can render images associated with model data. When clicked they send signals. How do TileRenderers access to data contained in model, while Model class does not provide access to them? They are all constructed by a TileRendererFactory. Concrete factories find appropriate data items by ModelIndex, and initialize concrete TileRenderers with it. They also bind tile renderer signals upon construction. The example shows the use of PreviewHolder in swatches dialog. Displayed items are paints. They are stored in PaintsModel. This class represents paint servers stored in document and built-in ones. It reacts to changes in document, updates it's entries and sends generic model signals. The model consists of PaintItems, that represent paints servers and provide access to SPPaintServer objects. PaintTileRenderer just fills it's content with pattern. Swatches dialog besides being a dialog, defines a slot that is executed when a tile renderer is clicked. It invokes apropriate SVG tree actions to set current object fill and stroke or execute "paint properties" dialog. TileRenderer can be implemented as plain class or it can inherit Gtk::Widget. The second solution would mean easier support for mouse and D&D events, but I'm not sure if it would affect performance (gobject construction, storing Gdk::Windows, initializing cairo context for each widget in GTK2). We will have several hundreds of those objects. Did you encounter any issues with Gtk performance? Which solution do you recommend? [1] https://www.dropbox.com/s/7nbg1uzk1sal2kn/new_swatches_ui.png [2] http://qt-project.org/doc/qt-4.8/model-view-programming.html [3] https://www.dropbox.com/s/r5ph6tgp5halal6/PreviewHolder.pdf [4] http://qt-project.org/doc/qt-4.8/model-view-programming.html#parents-of-ite… Regards, Tomasz

1 1

New video for the LPE Fillet-Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. I just release a new video for the LPE Fillet-Chamfer. Now have simplified interface and more features and bugfixes. https://www.youtube.com/watch?v=wJKzGhJULfc Thanks to Nathan, Liam, Josh, SUV, Mc- and all give feedback!

1 0

New LPE, New Video. Fillet/Chamfer
by Jabiertxo Arraiza Cenoz 28 May '14

28 May '14

Hi to all. Here is a video showing my new LPE. The branch is here[1].The video here[2]. Thanks to Josh Andler for give me the idea Also thanks very much to suv for the feedback and time inverted on it. And a special thanks to Liam P. White, without his help the LPE need a lot of hours to be.. or not to be. Bye, Jabiertxo. [1] https://code.launchpad.net/~inktxof/inkscape/fillet-chamfer [2] https://www.youtube.com/watch?v=HdsxhXPksgo

5 17

Change in pixels per inch?
by Tavmjong Bah 27 May '14

27 May '14

Hi TimeWaster and Nick, Alvin Penner has suggested that I contact both of you about a change to Inkscape I am pushing for: Currently Inkscape transforms non-pixel units (e.g 'in', 'cm') using the ratio 90 pixels per inch. This ratio is hinted at in SVG 1.1 but not explicitly defined (someday I'll blog about the history of this). CSS 2.1 does explicitly defined the ratio to be 96 pixels per inch, a standard that all web browsers as well a Batik have followed for many years. I recently proposed that in SVG one should be allowed to set this ratio but that idea was quickly rejected by the standards group. Previous to Inkscape 0.91 all dimensions inside of Inkscape were stored only as pixels values (despite allowing the user to enter dimensions in other units). As long as one did not import SVGs from other sources the ratio between px and in was not all that important. With 0.91, one can optionally set font-size to be output in points. To ensure consistency with what is rendered in Inkscape and what is displayed by other SVG renderers we should move to the standard 96 pixels per inch per CSS2.1. To make the change, two files must be modified: share/extensions/inkex.py share/ui/units.xml and probably the default export resolution should also be changed in preferences. Alvin is afraid this will cause trouble in the world of desktop cutters and plotters. Do you see this as a problem? Thanks, Tav BTW, the 0.91 release notes suggest that extensions relying on units other than pixels were already broken by the work on units.

4 9

Re: [Inkscape-devel] Widget c++-sification
by Tomasz Boczkowski 25 May '14

25 May '14

Resending: original message was send accidentally off-list. >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to keep a proper logical separation between Gtkmm UI objects and the functionality they trigger or state they manifest. The bulk of code ends up in plain C++ classes, while the Gtkmm widgets merely provide a thin layer to expose >> in the 'proper' manner. That might including moving certain functionality out of the widget classes themselves. I see your point. Could you please name some inkscape UI classes that preserve the separation? I would like to go on with SPColorSelector refactoring. In Inkscape color can be selected using one of two widgets: sp-color-wheel-selector, sp-color-icc-selector. They share common functionality in sp-color-selector. Currently there are six structures consisting of both Gobjects and c++ classes. I made a simplified diagram, listing possible options for refactoring [1]. 1) ColorSelector widgets contain a reference to their state (ColorSelector). It is accessible via getColorSelector() method. Optional ColorSelectorWidget abstract class provides the method. Parent UI component would initialize color selector widgets in ctor. Reference to widget would be kept in ctor only. Parent class would contain a pointer to widget state, returned by getColorSelector(). 2) Double inheritance. ColorSelector provides widget state. Concrete implementations inherit ColorSelector and aproppriate Gtk::Widget. 3) Full wrapper. Color selector widgets contain reference to their state and have full set of thin wrapper methods. They only call corresponding methods in ColorSelector. Which is the best? What is the suggested naming and namespacing of mentioned classes? Which of the options fits the separation between gtkmm and functionality best? [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf Regards, Tomasz On Sat, May 24, 2014 at 12:41 PM, Tomasz Boczkowski <penginsbacon@...400...>wrote: > >> A safe way to mitigate many of the C vs C++ issues with Gtkmm is to > keep a proper logical separation between Gtkmm UI objects and the > functionality they trigger or state they manifest. The bulk of code ends up > in plain C++ classes, while the Gtkmm widgets merely provide a thin layer > to expose > > >> in the 'proper' manner. That might including moving certain > functionality out of the widget classes themselves. > > I see your point. Could you please name some inkscape UI classes that > preserve the separation? > > I would like to go on with SPColorSelector refactoring. In Inkscape color > can be selected using one of two widgets: sp-color-wheel-selector, > sp-color-icc-selector. They share common functionality in > sp-color-selector. Currently there are six structures consisting of both > Gobjects and c++ classes. > > I made a simplified diagram, listing possible options for refactoring [1]. > 1) ColorSelector widgets contain a reference to their state > (ColorSelector). It is accessible via getColorSelector() method. Optional > ColorSelectorWidget abstract class provides the method. Parent UI > component would initialize color selector widgets in ctor. Reference to > widget would be kept in ctor only. Parent class would contain a pointer to > widget state, returned by getColorSelector(). > 2) Double inheritance. ColorSelector provides widget state. Concrete > implementations inherit ColorSelector and aproppriate Gtk::Widget. > 3) Full wrapper. Color selector widgets contain reference to their state > and have full set of thin wrapper methods. They only call corresponding > methods in ColorSelector. > > Which is the best? What is the suggested naming and namespacing of > mentioned classes? > Which of the options fits the separation between gtkmm and functionality > best? > > [1] https://www.dropbox.com/s/nvie03p9ee9r8ry/colorSelector.pdf > > > > On Wed, May 21, 2014 at 8:21 PM, Jon A. Cruz <jon@...18...> wrote: > >> On Wed, May 21, 2014, at 10:31 AM, Tomasz Boczkowski wrote: >> >> Thank you for the answer. >> >> >>Also, take care on what widgets you are looking at. We have a few >> groupings in our source tree that are meant to stay C. >> >> I started with src/widgets/sp-color-slider. I plan to continue with >> widgets related to fill and stroke dialog (sp-color-notebook, >> sp-color-scales, sp-color-wheel-selector etc.). Are they safe to port? >> >> >> >> Those should be OK... but in the 'proper' manner. That might including >> moving certain functionality out of the widget classes themselves. >> *Additionally* those I recognize as some of the first files I poked at when >> I initially joined Inkscape (before the project had its name). They're >> probably quite outdated by this point. >> >> Then also keep in mind that "sp" stands for Sodipodi, so when you move >> files you can drop such. Just be sure to do it in a source-control friendly >> way that won't break history. :-) >> >> >> >> >>>> 4) Should child widgets be stored as pointers as in glyph.h or >> directly as in text-edit.h? >> >> Which file are you referencing as "glyph.h"? >> >> src/ui/dialog/glyphs.h >> >> >> Ahh, that's an interesting question. >> >> For widgets, the design and intent of Gtkmm is to place children via new >> + Gtk::manage(). That ensures consistent object lifetimes and helps reduce >> memory leaks. For even stronger encapsulation often it's better to not list >> pointers as members in the public .h file, but keep them all to setup in >> the constructor. Since you won't have to delete them, you don't have to >> track them... for those cases where you set up events and handlers then add >> the child. That also goes on to event driven programming, and fewer bugs >> once you wrap your head around it. >> >> -- >> Jon A. Cruz >> jon@...18... >> >> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform >> available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> >> >

2 2

New LPE, New Video. Fillet/Chamfer
by Jabiertxo Arraiza Cenoz 21 May '14

21 May '14

Hi Nathan, i have problems whith my mail and get your reply searching by web the mailing list. Thanks very much for your help! Regards, Jabier. ################################################################ Hi Jabiertxo, There are various functions for this, the technical term is 'arc length', you can either compute a specific curves' total arc length (length), get an sbasis which maps time to arc length(arcLengthSb), or you can reparameterise a curve by arc length (arc_length_parameterization). There was an inverse arc length to time function somewhere too, but I can't remember what it's called. I think the easiest way to get what you want is roots(arcLengthSb(B) - desiredLength) which will return all the positions on B that are desiredLength from the start. njh On Mon, May 19, 2014 at 08:59:19PM +0200, Jabiertxo Arraiza Cenoz wrote: > Hello again. > Thanks to LiamW i undertand the time in bezier curves is influenced by > his curvature. Now i have a problem i want to select a time value at > specific distance. Is posibol actualy? > > Thanks, Jabier.

1 0

Widget c++-sification
by Tomasz Boczkowski 21 May '14

21 May '14

Hi! I started porting inkscape widgets to gtkmm and c++ and have a few questions: 1) There are two directories src/widgets and src/ui/widget. Is the former deprecated? 2) Should I move classes to src/ui/widget after c++-sification? 3) What is the proper macro to differentiate between gtk versions? GTK_CHECK_VERSION(3,0,0) or WITH_GTKMM_3_0? Regards, Tomek

3 8

Windows 64-bit build
by Johan Engelen 20 May '14

20 May '14

Hi all, With Partha's and Liam's help, we seem to be able to build for 64-bit Windows now. Some dependencies are missing, but it is a good start. For more details, please see http://wiki.inkscape.org/wiki/index.php/Compiling_Inkscape_on_Windows_64-bit All help is appreciated! (I do not know about the consequences for release. It'd be nice if we can release with a w64 version too, but I do not know about potential bugs with newer dependency versions. If anything, dragging the canvas seems quite a bit faster on my machine with the 64bit version) cheers, Johan

6 16

0.48.3.1 and 0.48.4 on Ubuntu 12.04 - Node Sculpting Problem
by clarkk 19 May '14

19 May '14

I hope someone can offer me some help. Please let me know if I haven't reported this in the right way or have omitted any info. Thanks in advance! My problem is that I am unable to sculpt text when using the node tool, as described at http://wiki.inkscape.org/wiki/index.php/Release_notes/0.44#Node_sculpting, and demonstrated in this video tutorial, http://youtu.be/_qqTAjBaeJ0?t=8m20s. These are the steps I take: 1) Create text with text tool 2) Node Tool 3) Select Text 4) Convert Object to Path 5) Select each path (each letter) - Note: the tutorial above shows that a selection box may be used to select all the paths at once, but this doesn't work for me. Hence, to work around this, I've selected each letter while the Shift key is held. Reasons for this would be welcome also! 6) CTRL+A (to select all nodes in selected path) 7) ALT+drag node - this MOVES all nodes together rather than sculpts them as described in the manual This is a video I made of the above process: https://dl.dropboxusercontent.com/u/14392713/temp/inkscape-sculpt-problem4.m kv I've also worked with a friend using Windows 7, where we have both done the same steps simultaneously. Hers works correctly (except the note mentioned in step 5) and mine does not. Any help would be very much appreciated! Environment: Ubuntu 12.04.4 (as per /etc/issue) Inkscape 0.48.4 (see my video below - installed from trunk ppa), but also tested in 0.48.3.1 (from Canonical repo) Default preferences (~/.config/inkscape deleted) System Alt key swapped with Win key (as per http://askubuntu.com/questions/118151/how-do-i-disable-window-move-with-alt- left-mouse-button-in-gnome-shell#272317)

2 1

Can't compile for Windows x64 (with btool)
by Liam White 18 May '14

18 May '14

Googled this issue, tried all the recommended solutions, and I found nothing helpful. When I run this command, btool -file build-x64.xml Everything compiles correctly, but the linker completely fails to find all external libraries: Make error line 459: LINK problem: c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagick++-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagickCore-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lMagickWand-6.Q16 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -latk-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -latkmm-1.6 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcairo c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcairomm-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lcdr-0.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lexif c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfontconfig c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lfreetype c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgc c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdk-win32-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdk_pixbuf-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdkmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgio-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgiomm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglib-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglibmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgobject-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgsl c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgslcblas c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgthread-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgtk-win32-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgtkmm-2.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lintl c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ljpeg c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llcms2 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpango-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangocairo-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangoft2-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangomm-1.4 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpangowin32-1.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpng c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpoppler c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpoppler-glib c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lpopt c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lsigc-2.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ltiff c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lvisio-0.0 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpd-0.9 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpd-stream-0.9 c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lwpg-0.2 The thought occurred to me that the issue might also affect the regular 32-bit builds as well. It didn't. They still compile fine. Johan, Partha, help!

3 4