Inspired by a blog text, I've spent some time adding "const" in a
number of places. Adding const tends to spiral out of control if it was
not used when code was written, meaning that you will have to add const
in many other places where it should have been when it was first written.
Please be very aggressive in adding "const" to any code you write. It
will help us understand code better and will prevent bugs from creeping in.
If "const" is new to you or you're a bit rusty on the topic, read this:
Thanks a bunch,
I've been asked by a friend to give a talk/tutorial about Inkscape
Extensions scripting for a local Python users meeting.
It's a slightly daunting task for me, given that
(a) I'm way more comfortable with C/C++ than Python
(b) My involvement with the extensions subsystem has been pretty minimal!
I'll happily put something together myself, based on the guidance on
the Wiki, but if anyone already has any additional useful
documentation/slides/tutorial material that they would like to
contribute, that would be very helpful, and might even encourage some
new contributors to the project :)
thanks as always for your insightful comments. Sorry for the belated
reply, I've been busy with work.
99 times out of 100, refactoring is best. However, there are exceptions.
Refactoring the menubar machinery in a way that works for all platforms
is a major undertaking. It would be a significant investment of time.
I think it would be nice to be able to provide a 0.48.4 release to the
Mac users out there, who have been left behind for quite some time.
I've come up with a solution that is not a hack, but not even
refactoring. As a matter of fact, Inkscape has already 80 % of the code
needed to work with a unified menubar.
Would you, Victor, or any other willing test this version:
It has a unified MacOSX menu for all windows/document/views. I don't
know, however, what the unified menu does to dynamic menu items. Check
marks are there and they seem to be ok for me.
This version has also a working python installation. The application
menu Quit item is not yet integrated with the app. It will be soon.
~suv, I've seen you comments in the bug reports and will reply, as time
> Commenting here even though the topic is quickly getting way above my
> head: Personally, I wonder whether it's really about adding some hack,
> or more about efforts at refactoring some of Inkscape's code base? As I
> had tried to convey with information provided in earlier replies, some
> of the issues with the menubar integration also seem to similarly affect
> Inkscape e.g. on Ubuntu under Unity with the global menu (no icons and
> keyboard shortcuts for menu items, the 'File > Open Recent' sub-menu is
> broken in the same way, the toggle state can get out of sync, e.g when
> working with multiple windows, etc).
> Possibly a somewhat related discussion, started during an earlier effort
> to advance the OS X menu integration of Inkscape:
> Maybe this should or could be addressed indeed by a refactoring of
> Inkscape's code base, possibly with increased focus on what GTK3 might
> offer right now or plans to support? AFAIU at least for the Quartz
> backend GTK3 already includes menubar integration code which does not
> require to depend / link against the external gtk-mac-integration
> library anymore (there's a small demo app installed alongside gtk3-demo,
> which uses the native global menubar on OS X ).
> Similarly, the problem with the modifiers in my understanding is likely
> to require quite a bit of refactoring - GIMP 2.8 is my reference in this
> regard: AFAICT the GIMP team rewrote large parts of the modifier code
> last year  (IIRC after some refactoring had occurred in upstream GTK2
> 2.24 first), and now the application out-of-the-box seems to handle
> modifier keys depending on the backend used for GTK2: on OS X 10.7, my
> local X11-based build of GIMP 2.8.2 has the (usual) 'Ctrl' modifier in
> shortcuts, whereas the Quartz-based build of the same GIMP version uses
> 'Cmd' instead. This is what I'd also like to expect from Inkscape.
I just opened a new report  about the deprecation of the Gdk thread
API. I know very little about writing threaded applications... would
anyone be willing to take a look at this, or at least give some hints
about how easy/difficult it will be to fix?
I created a 512x512 svg image to serve as the "master" logo and icon for
poshrunner. I then use inkscape from the command line to make png
renderings at 256,128,64,48,32, and 16 pixel square resolution, and then
use FreeImage to create a single ICO file that gets embedded into the final
ico. This involves two powershell scripts:
It would be nice to simplify this process. Could inkscape add multi
resolution ico export support? For the resolution it could be a series of
checkboxes for the accepted resolution (btw as of Vista the ICO format
supports 256x256). For the scriptable command line version the syntax could
I took over maintenance of the chocolatey (http://chocolatey.org) package
for inkscape. Chocolatey is basically yum/apt-get/fink/etc for windows. I
have a request and two offers. My request is that you list the package on
the download page. My first offer is that if you deem it appropriate I will
make someone on the inkscape core team a co-owner of the package. My second
offer is to integrate the package building into the inkscape windows build
process if you deem that appropiate.
Let me know your thoughts.
I'm lazy... please tell me where to store in preferences.xml the
'user-calibratable' grayscale conversion values for the grayscale view
mode. Something like:
(off-topic: the value itself is a floating point value between 0 and 1
that says how gray that primary color should be shown; 0 = black, 1 = white)