Devlibs in Launchpad?
by Krzysztof Kosiński
Can I put the Windows devlibs in a Launchpad project? (not in
lp:inkscape, but in a separate project like
lp:inkscape-windows-devlibs)
I have successfully compiled Inkscape on both Linux and Windows using
Waf, but there are 2 or 3 minor changes I need to make to the Windows
devlibs. Moving them to Launchpad would make them more accessible to
all developers.
Regards, Krzysztof
13 years
Re: [Inkscape-devel] Node tool committed to trunk
by Krzysztof Kosiński
W dniu 25 stycznia 2010 06:28 użytkownik ~suv
<suv-sf@...58...> napisał:
> Can I ask you two more general questions related to changes from your
> node-tool merge? (I'm just curious and trying to better understand):
>
> a) date removed from about-dialog
> I reverted this change locally because when testing different builds
> e.g. with different patch versions from the bug tracker that don't
> change the revision number - or re-building after external changes - I
> thought the build date at least as useful as the revision number (during
> development phases I wouldn't mind including the build time as well).
> I'd like to understand the reason to reduce the 'About' info to the
> revision number only, while trunk is still open for so many changes?
The problem was that the date displayed in the dialog was not the
actual date of the build, but the date of building the aboutbox.cpp
file. Since that file doesn't change too often, it would not be
accurate. I changed it so that the date was included in the version
string that gets written to inkscape-version.cpp, but probably it got
lost during the Bazaar transition.
> b) src/ui/icon-names.h
> When comparing available lists of icon names (wiki, src) I noticed that
> your new 'node-transform' icon has no entry in the macro list for icon
> names. Will the list in 'src/ui/icon-names.h' no longer be the most
> up-to-date list of named Inkscape icons?
I think that file wasn't a very good idea to begin with - changing the
names will cause the define names to be out of sync with actual names,
which is confusing, and changing any icon name or adding one will
cause extensive rebuilds, because icon-names.h is included in many
files. I have a different solution to the "list of all icons" problem
that I'll share later.
> p.s. btw - I am *very* pleased with the new transformation handles for
> selected nodes: it is the first time ever I can savor the ability to
> rotate nodes! Previously this action was accessible only by keyboard
> shortcuts which completely fail with many localized keyboard layouts
> ([,]) *and* - iiuc - bypass verbs and thus any custom keyboard shortcut
> mapping ;(
I'll consider adding a verb or GtkAction for each keyboard action in
the node tool. This problem of non-configurable keybindings is not
limited to the node tool, by the way, though probably it's the most
noticeable in the node tool due to the large number of shortcuts it
has.
Regards, Krzysztof
13 years
Re: [Inkscape-devel] Waf build branch
by Krzysztof Kosiński
W dniu 25 stycznia 2010 04:42 użytkownik the Adib
<theadib@...1439...> napisał:
> Krzysztof,
>
> does it build parallel (aka make -j2)?
>
> Thx, Adib.
Yes. If you don't give it any parameters it will use all available
logical CPUs. I use it on an i7 (8 cores) and in a Windows VM with 2
cores without any issues.
I'll put detailed instructions on how to build on Windows using
devlibs and the waf-build branch on the wiki, hopefully today or
tommorow.
Regards, Krzysztof
13 years
Waf build branch
by Krzysztof Kosiński
I pushed the Waf build system branch as:
lp:~tweenk/inkscape/waf-build
I would enjoy if someone tested it on Mac OS X and Windows, and
reported how it doesn't work. :)
The commands to build Inkscape are (in the top level source directory):
./waf configure
./waf build
Things that should work on Linux:
- building
- updating translation templates (via ./waf i18n)
- installation
Regards, Krzysztof
13 years
Re: [Inkscape-devel] Help regarding python extensions
by Jonatã Bolzan
On Thu, Jan 21, 2010 at 6:49 AM, Jonatã Bolzan <jbopen@...400...> wrote:
> Well, if you say that... here I go :D
>
> I want the extension passing for all the nodes. To be more clear, here I
> put an example of code from the extension "svg_and_media_zip_output.py":
>
> for node in self.document.xpath('//svg:image', namespaces=inkex.NSS):
>
> This line get every "image" object in the svg. In my case, I want to get
> everything that is drawn in SVG. I want images, shapes, text... do you
> understand?
>
> I know it's a bit silly question, but will solve some issues here.
>
> Thanks for the attention.
>
> On Wed, Jan 20, 2010 at 8:42 PM, Cédric Gémy <radar.map35@...8...> wrote:
>
>> Yep post here. I would also say that it would be great if we'd manage to
>> update wiki pages for extensions. They seem quite outdated. I wanted to
>> write some extensions few weeks ago (i already done some earlier) and
>> found that many things have changed so that the actual doc is not
>> enough.
>>
>>
>>
>>
>
13 years
Help regarding python extensions
by Jonatã Bolzan
Hi there!
I want to know if there are somebody here who know about python extensions
for Inkscape and have enough patience to answer some questions :D . If so,
please contact me at jbopen@...400...
Thanks anyway for the attention.
13 years
Warning cleanup of hash-iness
by Jon Cruz
Well... it looks like Krzysztof found us a nice, tricky problem in regards to the whole hash_map/unordered_list mess. What he has been tripped up by is one of those ugly problems with no simple solutions.
First, we have legacy code that is using a gcc extension. Not so good. Next the replacement has problems on many systems. So we don't have a tidy solution.
General questions for any thing with warnings, etc.
* Are the warnings critical? That is, do they indicate some immediate risk/failure?
If so, then we should address them sooner
* Do we need to be using it? That is, are there any alternatives to the code creating warnings?
Things such as vector instead of list, map instead of hash_map, etc.
* Can we encapsulate it? That is, do we need to leave things in .h files that other things include, or can they be moved inside specific files?
* Is there a clean way to fix at least some of the warnings? For some, this may be as simple as using an explicit variable instead of a temporary.
In this case there appears not to be
* Is it cross-platform? Remember, we need to keep Inkscape compatible with multiple platforms, including MS Windows, Linux, OS X, BSD, Solaris, etc.
I'll try to follow up on a few of these points.
13 years
Re: [Inkscape-devel] Writing extensions using Java
by Jesper Näsström
Hi,
I am contemplating a diagramming project (open source, of course) in Java
and believe Inkscape would make a great canvas.
However the degree of support for Java is unclear to me. It would need to
have dialogue boxes and be interactive, so a filter does not seem enough.
Guess there may be potential behind the curtain, or is this simply not the
best way to go ahead?
Best regards, Jesbox
13 years
toolbars
by bulia byak
Jon,
Thanks for your work on toolbars. It will be nice to have the ability
to make them vertical. However:
- PLEASE describe your changes in Release Notes
- I think it would be even more useful to have the ability to put two
or more toolbars on the same horizontal or vertical strip, next to
each other. Will your refactoring allow for that?
- I assume the now-vertical snapping toolbar is more of a
demonstration - I really don't see much reason to single it out for
vertical placement?
- Still, I couldn't re-attach the snapping toolbar into a horizontal
position anywhere. It's either its original vertical position at the
right, or floating. And re-attaching it to the original position is
also quite difficult - the magnetic zone is very small. Can you affect
this or is this unfixable in GTK?
- Will you be able to block standalone floating state for toolbars? As
discussed many times, they sink under the main window which makes them
unusable.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
13 years
node tool - color of helperpath
by unknown＠example.com
Hi Krzysztof,
I've been fiddling a bit with the new node tool. It's nice!
But, the color of the helperpath of a path with an LPE applied is confusing. The original path used to be colored red, and the LPE-path-parameter green (or to another color if set by the LPE itself). Could you change the green back to red for the original path?
Thanks,
Johan
13 years
