Upgrading the MingW pack
by Joel Holdsworth
Hi,
I'm running into a couple of problems with the MingW pack right now.
My main problem is that if you look at
mingw\i686-pc-mingw32\include\windef.h you'll see on line 12 that WINVER is
#defined as 0x0400 which indicates that the version of the Windows SDK is
very old - that WINVER value corresponds to NT 4.0! This is a little
troublesome for me because there are some newer APIs which I need to be able
to use, and I'd like to use them without defining home-brew versions of
those APIs. So is there any scope for upgrading to a more modern version of
the SDK?
Thanks
Joel
16 years
issue with .dxf
by Maude ALLAIS
Hi!
First of all, sorry for my bad english, I'm french!
I have an issue with inkscape 0.45.1 download in inkscape.org
Indeed I use this software to make some documents with the extension dxf.
Then these are used with the software robomaster.
But when I save my document as a dxf doc, the dos window appears (black with
nothing written) and then dissapear (normal by now)
But it seems that this step is not well done because after robomaster is not
able to upload my dxf doc. Moreover, all dxf documents have all the same
capacity" that is to say 76 octets, even if documents are differents (text
or picture)
Have you heard something like that before? and have the solution??
Thank you for looking,
If you want more information, do not hesitate to contact me!
Best regards,
Sialla
16 years
Re: [Inkscape-devel] docs
by Joshua Facemyer / Impressus Art
> It has been mentioned several times, but never done. I guess nobody has
> time for that...And in fact, i would do it
> well (i hope) for french but my english is so poor taht i just usually
> use the Release Notes as a basis for he EN version....Currently we
> have some ongoing work in French version of the user
> guide and not much of it in the English version
I'd be happy to put some time in working on the English version of what you have already in French. My French is not nearly as good as your English, but I'm sure we can manage something.
Is there currently someone heading English documentation? If so, please tell me where the best place is to begin.
Otherwise, I'll need someone to start at the basics with me - you can email me off list so I can get the info that doesn't need to be posted here.
> the more consistent it is the better
I agree, and it's useless to duplicate work, anyways.
I'd also be happy to dive into documentation of the new filter effects, and would be grateful for those who are working on them to help me get a layman's understanding of what they do. I realize that the best way is to actually use them, which I'll be doing, and read the specs, but that doesn't always bring better understanding :) Anyway, I may be able to begin the work in English which can be shared with the French version (and others).
I'll be really looking at the docs, as I get some free time.
Would someone be so kind as to point to all the current doc locations for me? Also, will I need any sort of commit access to those places?
Thanks.
jf
16 years
Dockable dialogs, todo list
by Gustav Broberg
Thanks for all bug reports, comments and wishes regarding the dockable
dialogs I've received in the last weeks! To sum it up, here's my todo
list for the time to come:
TODO (in no specific order)
---------------------------
* Allow in-dock dialogs to be expanded even if there's no
"slack". (I've got it kind of functional, but needs some more
work).
* Force GtkPaned to pass on F6 and F8 (i.e. those shortcuts can't be
used now when the dock is displayed).
* Make all the functionality provided by dialog-events.cpp work with
the new dialogs. Perhaps by moving it into the Dialog class. This
will lead a bit of to code duplication as long as there are "old"
dialogs around, which is bad, on the other hand it allows the code
to be C++-ified, which is good.
* Tackle the problems with dockable dialogs and multiple desktops,
i.e. the Dialog manager redesign.
* Scroll dock to display docked dialogs when requested, and needed.
* Remove old, obsolete object-properties dialog (a.k.a "Fill &
Stroke"). Add methods for setting a specific tab in the new F&S.
* Manage the Swatches dialog with the dialog manager, like any other
dialog.
* Fix minor problem with switching focus directly to dialog docked in
main window, when a floating dialog have focus. Also give focus to
a dialog that is deiconified.
* Fix all GDL runtime warnings.
* Fix all GDL compile time warnings.
* See if anything can be done about the clashing mnemonic
accelerators, i.e. allow them to be context sensitive for dialogs.
* Add any (if any) major, user visible problem from above that didn't
get fixed to "Known problems" sections in the release notes.
Wish list (in no specific order)
--------------------------------
* Add a "iconify/minimize all" button and bind a shortcut to it.
* Pan/zoom drawing depending on dock size, behavior toggled by the
current "Zoom drawing if window size changes" button.
* Allow dock to "start" from menu bar instead of toolbar (and thereby
giving it more space), by adding an option in "options.dock".
* Add another, horizontal, docking area. Potentially hard if we wan't
dialogs to be dragged and dropped between the docks.
I might have missed something, please tell if there's something
crucial that needs to be fixed before the code freeze that's not
already on the TODO list.
--
Gustav
16 years
Re: [Inkscape-devel] docs
by Joshua Facemyer / Impressus Art
On a similar topic as documentation, I'd be happy to add some news items
to the main page from time to time. I know that before I read the dev
list I would get discouraged by lack of posted news, but there's so much
going on.
How would I contribute news items?
What kinds of items would be desirable?
JF
16 years
Live effect preview
by unknown＠example.com
Thanks for adding the checkbutton Ted! But still, (all) effects crash for me on WinXP. Now that I have checked the "live preview" box, I get instant crashes when opening any effect dialog. So I cannot even uncheck the box to make inkscape work :(
Could you perhaps add a #define to disable live preview on windows until it works?
Does this crash for all Windows users? Or only for me?
Johan
16 years
Re: [Inkscape-devel] Hi
by Joshua Blocher
No, I mean select it with the selection and transformation tool (F1),
the Trace Bitmap has to have a target bitmap selected to trace use the
above tool to select it then trace bitmap.
Joshua L. Blocher
verbalshadow
On 9/14/07, Andreas.berg3@...128... <andreas.berg3@...128...> wrote:
> P.S. or did you ment some different like import,
> or afterwords mark the Bitmap as a path?
>
> I tried both.........
>
> Best Regards
>
> Andreas
> Am 13.09.2007 um 22:55 schrieb Joshua Blocher:
>
> > Andreas,
> >
> > It sound like you didn't select the bitmap before tracing/vectorizing.
> > Please check to see that is the problem.
> >
> > Joshua L. Blocher
> > verbalshadow
> >
> > On 9/14/07, Andreas.berg3@...128... <andreas.berg3@...128...> wrote:
> >> Hello im not really used to write in dev Lists, i even cant read
> >> source code :o)
> >>
> >> OK i have a Problem and maybe a Bugreport, so see im an not that
> >> much advanced User (like at my english, it says everythin :o)
> >>
> >> Id load today Inkscape, to try out, my aim is it to Trace or
> >> Vectorize ,or how ever its called in english, an Bitmap or better an
> >> Gif Image.
> >> My first Step is it to Import it, then i open the Option "Bitmap
> >> Vectorize" (i use it in German, so .....) and after i choose all my
> >> preferences i click on action, but it seams like nothing hapens.
> >> Id search and look at all manuals ( like i should do :o) did wait for
> >> over 10 Min. but, guess what, yeah nothin happens.
> >> So i dont know if i do some wrong and when it is like that i really
> >> cant expect what it could be.
> >>
> >> OK, Im using Mac OS X, 10.4.10 on an Intel Mac, yeah i know its
> >> running under X11 and i have to wait, but it starts up pretty fast.
> >>
> >> I really dont even know if its the right Place to talk about that,
> >> but i hope so, if not exuse my please, but tell me tahn to where it
> >> would be.
> >>
> >> If the one who answeres me is or know German, i would prefer that,
> >> cause english is not my first Language, and im writing like
> >> Simpleton, lol
> >>
> >>
> >> Best Regards
> >>
> >>
> >>
> >> Andreas Berg
> >>
> >> ---------------------------------------------------------------------
> >> ----
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Inkscape-devel mailing list
> >> Inkscape-devel(a)lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >>
>
>
16 years
initial inkscape user feedback from a regular illustrator user.
by Andy Fitzsimon
G'day guys,
Someone new has started here in Brisbane who comes from a heavy
illustrator background.
During her first day using Inkscape she's written up this short
document mentioning her initial reactions.
a good quote to summarize:
"I can find this stuff out by reading the manual. I'm just telling
you what isn't immediately apparent enough as I feel like it ought to
be."
------------------
Becc's Inkscape Hassles
--------
Magnification in/out buttons:
Wanting to zoom out, I hit the button showing the magnifying glass
with a minus sign on it, then clicked on the page several times
waiting for it to zoom out the same way it does when you've clicked on
the button showing the magnifying glass with + sign on it. It didn't,
but instead zoomed in. These buttons shouldn't imply they offer in/out
aspects of the same tool but not behave consistently with this
implication.
Zoom level indication:
The level of magnification indicator down beneath my work is out of
whack with the zoom tools being up in the menu above it: I don't
expect to hit a button on one menu and have to look to a field on
another one to see the changes it's effected. At the time that I
performed the above zooming in and out, I had nothing on my page and
was zoomed in to a level where I couldn't see the edges of the page.
As such, I was wanting feedback letting me know that my actions were
having some kind of effect. (I expected this to be zooming me out,
which turned out not to be the case – I was still zooming in, as
mentioned – but any feedback would've been helpful in letting me know
this button wasn't working as expected and that I should thus adjust
my approach.)
Ditto with the related shortcuts: I can hit Shift++ but not Shift+-,
which is inconsistent.
I can use a scrollbar to move my view horizontally but not vertically.
Makes moving my focus difficult. (NB: I later worked out I can scroll
up and down using the mouse wheel; okay, but having a scrollbar for
only one kind of pan when both kinds of pans are possible is
inconsistent and leads one to believe, as I did earlier, that only one
kind of panning is possible – otherwise, surely both would be
represented onscreen in the same way, y'know? Also, what do you do if
you don't have a wheel mouse?)
I'm not sure what to hold down to create a perfect circle. I seem to
have managed it accidentally by holding down Shift one time, holding
down Ctrl another time, and holding both together another time, but
none of these seem to create a perfect circle consistently: in each
case switching to an oval occurs if I'm not very careful about where
I'm dragging my pointer while I have the appropriate key/s held down.
If I want to select nodes, I seem to not only have to use the "node
edit" tool but must first select the entirety of the object(s) the
nodes are a part of in order to be able to do so. This slows me down
by adding in a step that doesn't seem necessary or logical. It also
took me some time to work out that the problem wasn't simply that the
node selection tool doesn't work – I really only kept trying because I
knew from having created that teardrop shape when you were standing
there assisting me that nodes could be selected and edited somehow –
which is going to present to potential converts from, er, say,
Illustrator, as bugginess and incompleteness.
Please let me rotate my object as easily as I can resize it, without
opening the Transform menu. Sometimes I don't know how many degrees I
want to rotate it, and sometimes I just want to turn it 'round 'til it
looks about right, so need to be able to wiggle it around
experimentally. :)
So, I'm beginning to form an idea of this program (and point this out
in the assumption that any user will do similarly) as having not just
paths with nodes like Illustrator does, but also having something
called "objects" that fit into all of this somewhere. My immediate
difficulty with that is this: I'm working at present with a shape
that's made up of a path. However I wouldn't know it to look at it
when selected, because the fact that it has a path outlining it isn't
readily apparent unless I not only select it but double-click on it.
I don't recall having to ever double click on something to edit it.
Is showing its path possible with just one click (also, can I see the
wire line of the path rather than just the nodes on it when I do so? I
can't make out the shape of what I'm working on when it's over/under
an object of the same colour!)? Could doing this perhaps serve also
to allow the user to easily see what's a shape and what's a path? As
it is, I'm still having difficulties conceptualising what the building
blocks of this program are (which is important because they're what
I'm going to use to develop my drawings etc as a user), and I wonder
if making the differences between the two more readily discernable
might assist in getting that across...
Is the node edit tool the only way I can alter a line once I've drawn
it? I'm accustomed to being able to select it and alter it with the
pencil – particularly when I'm using a graphics tablet, this is my
preferred method of working, cuz it makes using a computer to draw
just like using a pencil and paper. :(
I've hit a numeral a few times when meaning to type something or enter
a size or angle of a rotation into a text field and instead found my
view suddenly changed. This isn't a bug – I've obviously had the
focus in a place other than where I thought it was – but a suggestion
that the numbers on the keyboard not be used to change the view
without the use of the Ctrl or Shift key consistent with usual
shortcut behaviour.
Fill and Stroke colours are taking up so much real estate in their
respective menus that they shouldn't need. I know you're trying to
supply optimum control, but I'm being overwhelmed by details here when
all I want is to select an appropriate shade of pink to colour the
pieces of my exploded brains. Clicking on a colour swatch on the main
screen shouldn't open up a menu offering me options to choose between
fill, stroke, and stroke style, and then (once I've worked out that I
should stay inside the 'fill' tab of that menu) decide between what
kind of fill, whether I want to use RGB or CMYK or Pantone, the
colour(s) amongst those I want to use, etc, all at once. I just want
to change the colour. Wouldn't it make more sense when I click on a
swatch of colour to open up a menu offering me only colour options?
Sure, the colour is an attribute of a background; so offer the other
background options in the menu's other (unfocused) tabs – not options
having to do with strokes or stroke style.
As with the Fill option, the Stroke options are taking up a lot of
space because they're providing a lot of detail I don't immediately
need if I'm just clicking on, say, a swatch (in which case I want to
change the colour), or on a
I can't seem to shift objects up and down within a layer. Does this
mean that if I don't want to employ layers for something that before I
start drawing I need to think about the order in which I need to draw
objects, starting from the bottom up? :-/
Er... I can't scroll left to right using that scroll bar I mentioned
earlier! I can't remember if it was working then; it certainly isn't
now.
Joining two path ends together would be handy – something I use all the time
When I try to copy a style using the eyedrop tool, as an Illustrator
user I'm expecting both fill and stroke to be applied to the object
I'm working with. At the moment I'm getting only fill. Since I do
have the whole object selected and not just its fill, I'm not finding
any logical reason why both fill and stroke settings shouldn't be
getting copied over.
------------
16 years
Re: [Inkscape-devel] Scheme Scripting Console
by Ted Gould
On Sun, 2007-08-12 at 18:47 -0500, Samuel A. Rebelsky wrote:
> I'm the faculty member who supervises David and Soren's work. Thanks
> for your regular and rapid feedback on their work! I hope we'll find
> a way to get some Scheme scripting console into InkScape, even if
> it's not the one that they've written. Anyway, I thought I should
> respond to your two questions.
Great to meet you. I don't see any major barriers to using theirs, just
a couple details we need to work out.
> I don't have much to say about the document locking issue; if there's
> a better approach, I'm sure that they'd be happy to adopt it.
What would you guys think about building the patch without this? I know
it'd be slower, but then we could get some of the code into the tree so
that you'd have less of a branch to maintain.
> In terms of the TinyScheme issue, as best as I can tell, TinyScheme
> semms to have replaced SIOD as the implementation language for Script-
> Fu in the Gimp, starting with 2.3 (development) and 2.4 (release,
> eventually), but I'm working as an outsider. I'm pretty sure the
> discussion was in mid-2006. Let's see ... the developers mailing
> list had a note about the replacement in week 42.
<snip>
> If you'd prefer that Soren and David use guile, rather than
> TinyScheme, as the base implementation of Scheme for their InkScape
> scripting console, that's fine with me. (And probably with them.)
> However, it will delay their work somewhat, since they're starting
> classes again, and their available time is going away.
It really isn't as much about which Scheme interpreter, as much as how
to include it. The problem that we run into is that if we include it in
our source tree we end up maintaining that code. If we keep it as an
external dependency, someone else maintains it. I like less work if
possible. :)
It would also make sense that if GIMP is using the same interpreter that
we are, we make it an external package. That way bugs can be fixed in
one place. From some of the stuff I've been reading on the GIMP webpage
it seems that their version of TinyScheme is patched to work better with
GTK+ (UTF-8 fixes). Is that the version you guys have included?
> p.s. Your message to the Gimp developers' list did get posted, it's
> at http://www.gimpusers.com/mailmsg.php?1186687639.4436.4.camel%40bender
Still haven't received any responses. I'll see what I can find out.
I'll wait for "Monday" to finish around the world first :)
--Ted
16 years
misc dock issues
by bulia byak
Hi Gustav,
some glitches and questions as of rev 16035:
Docked dialogs don't scroll to be visible when I call them, if the
dock contains many dialogs scrolled down. Is this fixable?
Hightlighting the title of the dialog which was just called by a
shortcut is nice, but it does little else - the keyboard focus is
still not in the dialog. Or at least, I can't use Tab to travel
between widgets in the dialog as I was able in the dialog as a
top-level window - Tab works to select object on canvas no matter
what.
On the other hand, the accelerator keys (underlined in labels) work
indiscriminately across all dialogs and all UI in general. For
example, select an object, open fill&stroke and switch to HSL tab,
then press Alt+H. The first time, the Help menu is opened; the second
time, focus jumps to the H field in the dialog. This is a really bad
problem - few people use accelerators in dialogs but many call menus
by Alt+letter, so this needs to be fixed somehow. Is it possible to
limit the scope of the accelerators to the dialog only, so that they
only work when some widget in the dialog has focus?
By the way, if I can highlight the dialog with its shortcut, it would
be logical if it was also highlighted when I click some widget in it,
or just click on its title bar. Is this feasible?
Press Ctrl+Shift+W - the swatches dialog pops up. Press it again and
you get "** Message: Failed to find an existing dialog". Works with
other dialogs but not this one.
Is it possible to not show the separators between dialogs in the dock
with resize handles when resizing is not possible? This is misleading.
Open several dialogs, then open fill&stroke, iconify it, then restore.
It works but I get in the console:
(inkscape:3948): GLib-GObject-WARNING **: value "-313" of type `gint'
is invalid or out of range for property `preferred-height' of type
`gint'
Now that you've replaced them, can you remove the obsolete fill&stroke
code from src/dialogs? Note that the selected-style.cpp calls
sp_object_properties_fill and sp_object_properties_stroke, which open
the old (non-gtkmm) dialog and switch to the corresponding tab. Can
you provide similar accessor functions for the gtkmm docked dialog and
replace these calls?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
16 years
