ctrl-tab
by bulia byak
Now [shift-]ctrl-tab cycles through open document windows, as in most other
programs. Unfortunately GTK steals this key combination, so I had to run the
verb explicitly in event-context.cpp. This means it is subject to the same
problem as all other event-context shortcuts: it only works when mouse
cursor is over the canvas:
http://inkscape.org/cgi-bin/wiki.pl?EventContextGrab
It's very annoying, and I'm now going to try to attack this problem once
again. If anyone has any insights, please share.
Has anyone tested the new repr listener in node editor?
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
19 years, 4 months
sigc++ 1.2
by MenTaLguY
Okay, since the packaging situation for libsigc++ 1.2 seems better than
gtkmm, I will reintroduce a dependency on sigc++.
It should be available on almost all current Linux distributions, and
the older RPM-based distros should be able to find packages on
freshrpms.net (JonCruz tells me the RH 9 sigc++ package works on RH 8).
OS X is OK too, as fink unstable (and soon stable, also thanks to Jon)
also has it.
If y'all don't already have it, make sure you get the right version --
1.2.x, not 1.0.4 or something. Some distributinos seem to have a
slightly weird package naming policy with it.
Scream now if this will not work for you.
-mental
19 years, 4 months
gradient-vector.cpp
by Jon A.Cruz
I just removed sp_gradient_vector_dialog_close, since it was defined
but never used.
Was it just leftover cruft, or is there a reason to put it back?
19 years, 4 months
all keys work regardless of mouse position
by bulia byak
OK, I think I fixed that. Now the canvas always gets all keys, including
arrows, space, esc etc. (i.e. not only global verb shortcuts) so long as the
document window has focus. This closes a sore "known problem" from 0.36
release notes.
I'm not sure if my fix is "correct" but it seems to work. Previously, event
contexts received events only from the "acetate" item on the canvas (this is
an invisible item covering the entire canvas), and this item obviously can
only have focus when mouse is over it. We have tried putting event grab on
the canvas widget, but this apparently did not affect the acetate which, not
being a GTK widget, cannot have a grab. My solution is simply to call
sp_desktop_root_handler() from within the sp_desktop_widget_event() handler
(which receives all desktop widget events regardless of mouse position) but
only for GDK_KEY_PRESS events and only if the desktop's canvas has no
current item (because in that case, an item handler must be called instead
of root handler, and I don't need to do that anyway because this can only
happen when the mouse is over the canvas).
Please test the program thoroughly. This change may well have broken
something I did not notice.
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin....
19 years, 4 months
fixing NR precision issues
by MenTaLguY
Okay, really more generally what we need to do is replace e.g. NRRectL
and NRRectS with a single type ... maybe NRIRect.
That was the general effect of changing NRShort and NRLong to the same
width anyway, since the structures don't differ at all except in the
precision they use.
-mental
19 years, 4 months
[Fwd: Re: purpose of s/double/Coord/ change in nr-types.h]
by MenTaLguY
-----Forwarded Message-----
From: MenTaLguY <mental@...3...>
To: Peter Moulder <Peter.Moulder@...38...>
Cc: Nathan Hurst <njh@...5...>, Inkscape ML <inkscape-devel@...142...ge.net>
Subject: Re: purpose of s/double/Coord/ change in nr-types.h
Date: Thu, 01 Jan 2004 15:47:01 -0500
On Thu, 2004-01-01 at 04:55, Peter Moulder wrote:
> I believe that in revision 1.13 of src/libnr/nr-types.h you introduced a
> `typedef double Coord' (CVS comment "removed *S variants of NR structs").
>
> Can you please document where Coord is to be used, or the purpose of
> this change?
>
> Knowing the purpose of the type, or how the typedef may change in
> future, helps programmers to decide when to use Coord and when to use
> double.
The purpose of NR::Coord and NR::ICoord are to provide "real" and
integer types used for storing coordinates in the rendering subsystem
(and consequently having sufficient precision for that purpose).
(I'll add doxygen comments accordingly)
The motivating factor here was eliminating the entire class of bugs
caused by switching between various precisions so much, particularly in
the case of integer arithmetic.
If Coord and ICoord are used consistently for math involving coordinates
(and have sufficient precision), we'll have many fewer headaches with
precision issues.
I erred on the side of using Coord everywhere at first because I think
it's less work to revert the few instances where it's not appropriate
rather than the other way around.
Probably non-libnr code should have little reason to use them
(operator*(double, NR::Point) should probably remain with the double,
though maybe it should have an NR::Coord variant too).
I will let Nathan be the ultimate judge of where it's appropriate and
where it's not, since the NR:: stuff is his purview at this point.
-mental
19 years, 4 months
Inkscape Status 2003-12-31
by Bryce Harrington
Project Status
Wednesday, December 31, 2003
The past couple weeks have seen work in a variety of areas. Ctrl-click
selection within groups, including multiple and nested groups has been
implemented. The new inset/outset capability is receiving a lot of
testing attention. The Win32 build of Inkscape has also been a focus of
development efforts over the past couple weeks, and it's expected that
0.37 will see much improvement in this area.
A few issues have arisen and been resolved. The issue of handling
comments in SVG documents was brought up by a Sodipodi user; comments
are not always preserved when editing in Sodipodi or Inkscape.
Fortunately, some good ideas have been voiced for addressing this.
A second and much more critical issue has been raised regarding Gtkmm.
As planned since early in the project, we began incorporating Gtkmm into
Inkscape following the 0.36 release. Quickly it became evident that
this introduced severe dependency issues. Gtkmm 2.x is not available
commonly on most Linux distros. On Windows it adds to the DLL download
weight. Most distressingly, it isn't yet ported to OSX. Due to these
reasons we've decided the best course of action is to postpone use of
Gtkmm until the library is more widely available.
Statistics Nov 02 Nov 15 Nov 29 Dec 15 Dec 31
========== ====== ====== ====== ====== ======
Lifetime Rank on SourceForge: 6103 4391 3676 2452 2444
(56.2%) (68.5%) (73.6%) (82.4%) (82.5%)
Max Week's Rank on SourceForge: 6023 62 37 27 22
(56.8%) (99.6%) (99.8%) (99.8%) (99.9%)
Total SF Page Views 200 * 50,000 86,000 107,600
Total SF Downloads 0 * 1700 3640 4,751
Total Freshmeat URL Hits 0 746 1121 2237 2567
Total Freshmeat Subscriptions 0 16 19 28 30
Lines of Code in src/: 115,754 115,901 116,970 132,134 165,664
Code lines 100,549 132,458
Comment line 11,591 12,234
Blank 20,559 21.540
Lines of Docs in doc/: 1,135 1,135 2,100 2,225 2,615
Lines of content in website: 74 1,173 1,624 2,090 2,261
Size of the Inkscape wiki: 0 3,700 5,737 7,385 11,062
Hours since last ChangeLog mod: 90 6 2 21 0.8
Bugs open/total: 0/0 9/15 40/51 67/111 66/130
Features open/total: 0/0 18/18 23/24 40/45 103/115
Patches open/total: 0/0 1/ 6 5/20 6/25 4/32
CVS Commits (as per inkscape-cvs): 148 481 963 * 1580
Inkscape-devel membership: 4 49 61 64 65
Inkscape-announce membership: 0 9 14 16 20
* - Statistics unavailable
19 years, 4 months
Re: [Sodipodi-list] <!-- Comments -->
by Jonathan Phillips
Maybe a warning dialog or a status bar update would be positive to
notify the user if a comment is orphaned in someway. I know though this
would require some intelligent coding.
jon
On Wed, 2003-12-31 at 15:17, MenTaLguY wrote:
> I guess one thing to think about is how to deal with Sodipodi's
> "advertising" comments if comment preservation were added.
>
> Obviously we wouldn't want to add an advertisment comment to the
> document if one already existed, or they'd start piling up every time
> one was saved.
>
> -mental
--
Jonathan Phillips <jon@...15...>
19 years, 5 months
Re: [Inkscape-devel] Nuke the fake config?
by bulia byak
>I didn't think about the gen-nrconfig change very closely when it was
>first made, but in retrospect, since NRShort is a general-purpose type
>with a precision implied by its name, changing its precision is probably
>a bug in itself.
>
>The correct fix is to replace uses of NRShort that require more
>precision with a type that provides it -- e.g. NRLong, or better gint32.
Why "better"? What if one day, we need 64 bit precision - do a global search
and replace again? The NR* stuff was there exactly for this: a layer of
abstraction that allows to change the actual precision quickly - and it was
not "a bug" because the typedefs are there for exactly this purpose (and
they were not "general purpose" becaue the NR prefix limited their scope
pretty narrowly to the NR subsystem). Frankly I don't understand why it was
necessary to kill it and replace with hard-coded 32-bit types (I can
understand getting rid of nr-config.c, but not this). Anyway, it's not my
domain, so please fix it one way or the other, so long as it's fixed :)
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin....
19 years, 5 months
