- Inkscape Devel - Inkscape Mailman

Make inkscape remember dialogs window status (bug #171579)
by John Smith 20 Dec '11

20 Dec '11

I have put an improved patch that addresses most of the issues in launchpad https://bugs.launchpad.net/inkscape/+bug/171579 >> 1. It only works with dockable dialogs (not with Text and fonts, XML editor, etc.). Now works with both dockable and non-dockable dialogs >> 2. It doesn't work correctly with dialogs docked in a floating window Docked dialogs in floating window are now remembered as open. Currently the basic status of visible/hidden, floating/docked, size and position are saved to preferences. However we dont save the complete docking status (such as docked above/below/left of/right of, iconified, dock in floating window etc), this patch mainly addresses the visible/hidden status of dialogs. >> 3. The minimize status of the docked dialogs is not remembered (they are considered closed). Iconified docked dialogs are now remembered as open, but are docked (not reiconified) on open (same as 2. above, currently no code to open a dialog as iconified) >> 4. It doesn't restore all the locked/visible icons of the Layers dialog. Layers icons fixed >> 5. The status is updated when the dialog is opened or closed, and doesn't necessarily reflects the status of the last closed Inkscape window. Saves the last windows status correctly in all the use cases i tried. Regards, John. ----------------------------------------------------------------------------------------------------------------------- Send big files for free. Simple steps. No registration. Visit now http://www.nawelny.com

1 0

GTK+ version dependency
by Alex Valavanis 20 Dec '11

20 Dec '11

Hi All, As we move towards GTK3 compatibility , we're going to run into a lot of backward-compatibility issues. For easy cases like bug #800565 [1], we can just add code alternatives, but there are other situations where this isn't really desirable. An example would be fixing deprecated symbols in our copy of GDL... I'd really prefer to import changes from upstream rather than increasing the size of our diff any further. However, the upstream fix for one of the GDL issues requires gtk+ 2.22. The question is when to start bumping the gtk+ version requirement for Inkscape? If we want to support LTS linux distros, we could be waiting a **very** long time. For example... Ubuntu Lucid (LTS) has no GTK+3 library, and only gtk+ 2.20, and is supported until April 2013. Options include... 1. Keep our linux LTS-release support rigorously; don't make any gtk code updates that introduce a gtk > 2.20 dependency (unless there are easy code-alternatives for backward compatibility). Eventually move on when common LTS distros reach end-of-life. 2. Gradually inch forward with dependency versions. Drop linux LTS-release support for trunk, but maintain support for all current non-LTS distro versions (e.g. Ubuntu Maverick and higher). 3. Charge ahead mercilessly towards compatibility with the current stable GTK version (currently 3.2). Break support for linux distributions as required, and laugh heartily in the faces of the grieving users. Any thoughts? AV [1] https://bugs.launchpad.net/inkscape/+bug/800565

6 8

Floating Dialogs with multiple documents
by John Smith 19 Dec '11

19 Dec '11

Is there a plan for how floating dialogs should be managed with multiple windows ? Currently each document has is own set of dialogs and a dialog-manager to control them. The dialog-manager ensures there is only one instance of each dialog per document. So with 2 documents open, you have 2 dialog-managers and can have 2 identical dialogs floating around at the same time (and several bug reports relating to this below) All floating dialogs respond to the current active document. When a document is closed all the dialogs opened with that window are reattached to the next open window and remain alive until the application is shutdown. Hence memory usage grows for each new window that is opened and is not reclaimed when documents are closed. Users have requested 2 different styles of operation (1) Have floating dialogs per document, but close/hide them when a document is closed/unfocused (258013) (2) Have at most a single instance of each floating dialog that works across all open documents "gimp style" (317439). Which is the preferred behaivour ? (1) Looks simpler because (2) needs to deal with dialogs docked with a document and floating dialogs across the whole app, and with new instances launched (such as double clicking a file in the file manager) Related bugs * https://bugs.launchpad.net/inkscape/+bug/317439 * https://bugs.launchpad.net/inkscape/+bug/258013 * https://bugs.launchpad.net/inkscape/+bug/216693 ----------------------------------------------------------------------------------------------------------------------- Send big files for free. Simple steps. No registration. Visit now http://www.nawelny.com

1 0

Toolbars architecture
by Romain de Bossoreille 18 Dec '11

18 Dec '11

Hi, I'm working updating the wiki to have a more clear view on modules, works to be done and tips for developpers. Here I'm working on the toolbars: http://wiki.inkscape.org/wiki/index.php/User_Interface_Modules#Toolbars Some questions: * Nearly everything is in src/widgets/toolbox.cpp. The final goal is it to have breakdown in per-toolbar-files (like for exemple we have actually for Select and Gradient toolbars) + toolbox.cpp file? o If yes, can I work at this breakdown or is there already a work to do this? * Is there a C++ migration guidance for toolbars? I've found nothing. * Can toolbars files move to a dedicated directory (ex: src/toolbars and then the C++ version in src/ui/toolbar) or will they still appears as widgets? * In files we are speaking about "toolbars" and "toolboxes". What's the good word? I think it's toolbar, but just to be sure... Moreover, I would like to propose you to have one page per toolbar in the wiki with a screenshot, list of functions (like a user documentation but that could be also usefull for developpers to find their way), links to related source files and (if we can have an automatic link between the wiki and launchpad) links to all bugs/wishlist related to it (with a system of tags). What do you think about it? Can I work in this direction? Thanks, -- *Romain de Bossoreille*

4 6

Inkscape::UI::Dialog::PanelDialogBase .cpp and .h file
by Romain de Bossoreille 16 Dec '11

16 Dec '11

Hi, I was working filling the wiki about User Interface. Is it normal that the file src/ui/dialog/panel-dialog.h does not have a .cpp? This file contains prototypes and source code of all functions of the class Inkscape::UI::Dialog::PanelDialogBase. For clarity and compilation optimisation, would it be better to break it in a .cpp and .h files ? Thanks, -- *Romain de Bossoreille*

2 2

Make inkscape remember dialogs window status (bug #171579)
by Nicolas Dufour 16 Dec '11

16 Dec '11

Hello, The wishlist report bug #171579, "Make inkscape remember dialogs window status", has been recently patched by John Smith. (https://bugs.launchpad.net/inkscape/+bug/171579) The patch compiles correctly on Windows XP, OSX and Ubuntu, and behave *almost* as expected. But: 1. It only works with dockable dialogs (not with Text and fonts, XML editor, etc.). 2. It doesn't work correctly with dialogs docked in a floating window. 3. The minimize status of the docked dialogs is not rememberer (they are considered closed). 4. It doesn't restore all the locked/visible icons of the Layers dialog. 5. The status is updated when the dialog is opened or closed, and doesn't necessarily reflects the status of the last closed Inkscape window. 1, 2 and 4 are probably out of the scope of the patch, but fixing 5, and maybe 3, would make the patch committable for 0.49 IMHO. 5 is debatable though. Should we save the status in the preferences when the last document is closed, or save it on a per document basis? Tests and comments are welcome! Regards, -- Nicolas

1 0

svg cleaner
by Alexandre Prokoudine 13 Dec '11

13 Dec '11

Hi, Today I got a mail from developers of a new SVG cleaning app called... *drumroll*... SVG Cleaner :) Source code is at Launchpad: bzr branch lp:svg-cleaner There are builds for Ubuntu: https://launchpad.net/~svg-cleaner-team/+archive/svgcleaner The app seems capable, developers are seeking input from experienced users. Alexandre Prokoudine http://libregraphicsworld.org

1 0

DHW file input extension
by Nikita Kitaev 13 Dec '11

13 Dec '11

A couple of months ago I modified someone's BSD-licensed DHW to SVG converter and turned it into an Inkscape extension. DHW is the proprietary format used by DigiMemo digital notepads (writing on the notepad with a special pen will record all of the penstrokes and save a copy of the writing onto an SD card). Right now the code is up on github [1]. It's a 215-line perl script, plus the accompanying INX file. I'm wondering if it would make sense to do something else with it, like adding it to an extension repository or maybe even including it with Inkscape. Any suggestions? ~Nikita [1] https://github.com/nikitakit/DM2SVG

3 4

Re: [Inkscape-devel] Re : Adding half tones pattern to SVG filters
by gespertino＠...400... 12 Dec '11

12 Dec '11

2011/12/11 Ivan Louette <ivan_louette@...48...>: > Thanks ! It's a very nice filter in GIMP indeed ! > > But SVG filters are non destructive and another advantage is that you can > combine several filters in one to create powerfull and customizable non > destructive custom effects. You're welcome! I mentioned GIMP's newsprint just as a reference of the needed features (dot shape, resolution, channels, etc) and UI. Using similar sets of features, names and UI distribution would make the SVG filter more familiar for GIMP users and vice-versa. I know SVG filters are different and of course I'd love to have a non-destructive filter instead of a one-time raster effect. Well, I'd love to have non-destructive filters in GIMP too, but that's far in the GEGL horizon. ;-)

1 0

Useful functions
by Josh Andler 10 Dec '11

10 Dec '11

Hey All, I stumbled across some videos a while back relating to some plugins for Illustrator that provide some pretty cool functionality and wanted to share, I just don't believe I did on the list (hopefully I'm not repeating). Do we have an appropriate page in the wiki for me to add them or does anyone think it would be more appropriate to just add a number of RFEs to the tracker? This first one shows some pretty useful color functionality you normally see associated with raster apps but is stuff that would rock to have for use in the vector space. Yes we have extensions that provide some of the functions, but they're destructive effects. http://www.youtube.com/watch?v=FRthJrsYepg This live half-toning stuff is definitely sweet. http://www.youtube.com/watch?v=RLOVqTE9Zy8 When we finally get to a point where we can produce proper PDFs for print, this would be some fantastic functionality to have (especially with the costs of home printing supplies). http://www.youtube.com/watch?v=xnGgtQAXf8U Just thought I'd share... Cheers, Josh

3 2