Extensions - Slider in Int and Float widgets
by Nicolas Dufour
Hello,
Revision 10103 adds horizontal sliders to the Int and Float extension widgets in
order to make parameters a bit easier to handle.
It perfectly fits large numbers (colors or angles related values) but may be
less efficient with small range parameters (as in the SVG calendar extension).
Thus I've implemented two modes (mimicking the radiobutton parameter), full
(default, with slider) and minimal (no slider) that can be used by adding an
appearance="<mode>" attribute to the int or float element in the inx file or
internal extension structure. The size of the slider is the same for all
widgets, 200px (about the same as the sliders used in Gimp).
Please test and comment!
Regards,
--
Nicolas
12 years, 2 months
plans on 0.49
by Alexandre Prokoudine
Hi,
Do we have any plans re 0.49 and GSoC? Do we want releasing 0.49
before work on GSoC projects starts (in case we are accepted) which
means end of May? If not, do we want releasing once a year which means
0.49 around August?
Would it make sense figuring out now where we are currently and what
we could for 0.49?
Alexandre Prokoudine
http://libregraphicsworld.org
12 years, 2 months
Command line interface on Windows
by Jason La
Hi Inkscape community,
Thanks for the app, it is proving to be very useful. For whatever
reason, the .NET framework does not include any kind of SVG handling --
so Inkscape has been endlessly useful. I'm using it for a pretty simple
purpose - converting SVG files to PNG or JPEG images.
I'm just following the instructions from the FAQ to let the devs of our
common usage of the CLI.
Thanks again,
Jason
Jason La
Associate Software Developer
Tel: 805-898-8508
www.alg.com <http://www.alg.com/>
Confidentiality Notice:
This e-mail may contain confidential, proprietary information of ALG, A DealerTrack Company. It is intended solely for the named recipient(s) listed above and should be maintained in strictest confidence. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you have received this e-mail in error, please immediately notify the sender and delete this information from your computer and destroy any related paper copies.
12 years, 2 months
possible save dialog bugs on Windows
by Michael Grosberg
I'm only seeing it on a single machine at work, but please take the time to see
if you can reproduce it. perhaps it's just that one machine. I waited for 48.1
just to be sure it's not already solved but it seems like I still have this
problem:
When I create a new file and then attempt to save it, I have to explicitly
add the "svg" extension. If I don't, the file is saved without an extension.
Another issue I see on all both home and office machines:
When I do a "Save As...", the save dialog opens with the file name field
empty, when in most other applicatios it contains the current file name.
Both issues are on Windows, I haven't tested on my Linux partition yet.
12 years, 2 months
Re: [Inkscape-devel] Merging the Cairo branch
by john cliff
2011/3/15 Josh Andler <scislac@...400...>:
> Hey,
>
> So, I really think that we should entertain the idea of merging the cairo
> branch into trunk. The plan has been for us to not release 0.49 until it is
> ready, so the couple outstanding bugs in cairo shouldn't be a huge
> deterrent. We could also set up a PPA to produce the trunk builds of cairo &
> pixman so that fixed libs are easily installable in the meantime (at least
> for people using debian-based systems). I was talking to John Cliff and he
> put forth a very good point which is that we really need to get as much
> testing as possible on it prior to a release.
>
> Before it gets asked, yes Jon, color management is broken in it atm. The
> likelihood of it getting fixed in a branch as opposed to trunk is next to
> non-existent though...
>
> So, would people be okay with a little breakage of existing functionality to
> get more testing of a cairofied Inkscape? bulia, I included you in the to
> line here to help gauge the acceptability of this proposal.
>
> Cheers,
> Josh
>
I think the more we can use this code the better, and having it tucked
away in a branch isnt achieving that. Putting it in trunk forces us to
fix what we find, and means we dont only start that process once cairo
is uptodate enough in the distros. If we're gonna have to wait for the
distros to be ready for us, we might as well be good and ready for
them.
Cheers
John (sim)
12 years, 2 months
Fwd: [Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
by Igor Novikov
On Tue, Mar 15, 2011 at 11:53 AM, Jasper van de Gronde <
th.v.d.gronde@...528...> wrote:
> On 2011-03-13 15:52, Vladimir Savic wrote:
> > On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:
> >> Is there any plan how we will speed-up performance in future. I mean:
> >> - fast (visual) response to the user
> >> - fast rendering
> >>
> >> I know that we have:
> >> - tiling the image into pieces to decrease user response time
> >> - add OpenMP to filter functions
> >>
> >> On the roadmap is conversion to cairo. But cairo does not render filters
> at all.
> >> I read that LLVM could speedup when generating the filter code .....
> > Maybe I misunderstood the concept behind filter rendering, but what
> > about joining efforts with GEGL guys and using that library? I guess it
> > will develop faster, both big apps that would use it (Inkscape and GIMP)
> > will benefit from joined development, bugs will be fixed faster, etc. If
> > I understand correctly, GIMP will use GEGL for pixel computations too
> > and pass the resoult to cairo for drawing on canvas.
> Could we please slow down just a bit. Basically someone has come and
> claimed, with some justification, that Inkscape is slow. It is, at least
> in some respects (no one files bugs for cases in which Inkscape performs
> marvelously). But we are working on performance issues continuously and
> I think pretty much any Inkscape developer knows at least a few things
> he would like to speed up.
>
> As for getting some results, apart from some UI issues, which are
> important but which are not exactly my specialty, filters are probably
> the main cause of perceived slowness. I would like to make a couple of
> remarks about that. Inkscape mostly has implementations that are quite
> accurate, which often results in slightly worse performance than you
> might otherwise see.
>
May be Inkscape has accurate implementation but Inkscape document
model is highly non effective. There is a simple comparing test. Just
create
1000 rectangles, convert they into paths and measure memory usage in
Inkscape, CorelDRAW and sK1. You will get approximately following numbers:
Cold start/With document
Inkscape 0.48 62Mb/140Mb
CorelDRAW X3 47Mb/63Mb
sK1 0.9.1 51Mb/62Mb
So for the same drawing applications use:
Inkscape 0.48 78Mb
CorelDRAW X3 16Mb
sK1 0.9.1 11Mb
The test file you can fetch here:
http://sk1project.org/files/test1000_rects.svg
If you multiply objects (10k or more) you will see that Inkscape allocates
0.5Gb
and more whereas Corel/sK1 uses less than 100Mb.
Actually similar issues are observed in all mature applications because
initial
architecture was not designed with all the implemented features. Gimp,
Scribus, Inkscape and our sK1 already faced with this problem. CorelDRAW
has passed this milestone in ver.10
I think you remember that we have presented Cairo-based rendering in
sK1 on LGM2007 and since that time we have a lot of experience in this
issue (whereas "cairofication" for Inkscape is upcoming feature). Using
this experience I would say that "cairofication" doesn't resolve all
Inkscape rendering problems because Cairo (at least current stable
version) is not fast.
Concerning our project we have decided reimplementing sK1 and
UniConvertor from scratch because the further development of just
stuck in the architectural issues. We hope reporting results in our
presentation on LGM2011, so I think we could discussing this in
Montreal and it could be really useful for further Inkscape development.
--
Regards,
Igor Novikov
sK1 Project
http://sk1project.org
12 years, 2 months
Fwd: Inkscape Wiki page DotDotDot has been changed by Airhogs777
by unknown＠example.com
The site referenced, http://www.dot-dot-dot.nl in the subject page,
http://wiki.inkscape.org/wiki/index.php/DotDotDot looks like a parked
domain from where I sit. The Wikipedia entry,
http://en.wikipedia.org/wiki/Dot_Dot_Dot_(magazine) points to
http://www.dot-dot-dot.us which looks more like something, but the
site doesn't display well in Internet Explorer (Intentional?) and
doesn't have much functionality in Firefox. Is Dot Dot Dot Magazine
really useful to the Inkscape community?
---------- Forwarded message ----------
From: WikiAdmin - acspike@...34...
Date: Mon, Mar 14, 2011 at 7:13 PM
Subject: Inkscape Wiki page DotDotDot has been changed by Airhogs777
To: NeoPhyte Rep <InkscapeWiki.NeoPhyte_Rep@...2295...>
Dear NeoPhyte Rep,
The Inkscape Wiki page DotDotDot has been changed on 02:13, 15 March 2011 by
Airhogs777, see http://wiki.inkscape.org/wiki/index.php/DotDotDot for
the current version.
See
http://wiki.inkscape.org/wiki/index.php?title=DotDotDot&diff=0&oldid=1172
for all changes since your last visit.
Editor's summary: -
Contact the editor:
mail:
http://wiki.inkscape.org/wiki/index.php/Special:EmailUser/Airhogs777
wiki: http://wiki.inkscape.org/wiki/index.php/User:Airhogs777
There will be no other notifications in case of further changes unless
you visit this page.
You could also reset the notification flags for all your watched pages
on your watchlist.
Your friendly Inkscape Wiki notification system
--
To change your watchlist settings, visit
http://wiki.inkscape.org/wiki/index.php/Special:Watchlist/edit
Feedback and further assistance:
http://wiki.inkscape.org/wiki/index.php/Help:Contents
12 years, 2 months
[Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
by ~suv
Could some of the devs help with bug triage and comment on this recent
report?
~suv
-------- Original Message --------
Subject: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor
Date: Sat, 12 Mar 2011 18:49:58 -0000
From: Gary <733966@...1882...>
Reply-To: Bug 733966 <733966@...1882...>
Public bug reported:
Guys truly it is time to stop adding features to Inkscape and go back
and refactor the code to fix bus and the terrible performance issues.
There is little excuse for it to be at ver .48 and performance to be
slow sluggish. Even the about box repaints the logo/image very slowly.
That alone would have told me I have performance issues. At what point
do you stop trying to add features and go back and address performance?
My recommendation is to get a better handle and control over the
development effort and split your team and branch to allow some to work
on new features and others the refactoring of the code and eventual
merge. When I launched it for the first time a while back I nearly
laughed at the performance. Then expecting someone to address it in .48
would have been an expectation.
Do everyone a favor and place in your roadmap a REAL item to address
performance and refactoring the code. This sluggish performance is
across ALL platforms. For any developer on the team to be tolerant of
such or even think of asking what hardware is foolish. Any junior level
developer can easily determine the performance issues are within the
code.
As of now I am going to kick off my own branch of this code and move it
to QT4 for the UI and begin refactoring for performance. I will make
that split in the branch available for those who want a highly
performance version of InkScape.
I would invite you to address performance.
** Affects: inkscape
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Inkscape
Bug Team, which is subscribed to Inkscape.
https://bugs.launchpad.net/bugs/733966
Title:
Inkscape way to SLOW - Refactor
12 years, 2 months
Inkscape Website Progress...
by Ian Caldwell
Hello,
here's an update on the website. We have made some nice progress and it
is defiantly coming along. It's going to be launched in phases. Phase #1
will be the main site with all the content and Phase 2 will consist of
various things for the user allowing them to be able to post their own
tutorials and plugins etc. However in order to do that we need help!
We need the following:
1. content writers to go through the site and improve on the existing
write ups.
1. Additional old news needs to be ported over. We ported over all of
2010 and 2011 but we need all news ported over
2. Django developers to finish up the last few features
After all that
3. we need translators to translate the various parts of the website
You can follow the project here:
https://code.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web
Also the site is visible at http://dev.inkscape.org please feel free to drop
by on irc.freenode.net and join #inkscape-web
Thanks,
Ian Caldwell
12 years, 2 months
Re: [Inkscape-devel] Inkscape Website Progress...
by Pajarico
2011/3/8 Hinerangi Courtenay <duckgoesoink@...400...>:
> Chris Morgan wrote:
>
>> This is the most important part. There's a significant quantity of new content needed for the website which just hasn't existed before. I think the main thing we need is just lots of basic content which can be refined later. Most of the pages aren't created yet; some have been designed but don't have all their content yet.
>
> Agreed completely. As I said on the user list, much of the text on the brand new pages was written by me for the mockups (I'm a terrible copywriter, so there's unfinished Lorem Ipsum and blah blah stuff), and much of the other stuff was brought straight over from the current site - some serious tidying is in order, and will help speed things up significantly.
Why is there commit 50 by Chris Morgan reverting my additions to Lorem
Ipsums texts (see column "More stuff" in
content/en/about/features.html)?
I could understand that maybe I added more content than I should have,
but that doesn't explain why parts were reverted to Lore Ipsum. Also,
the style of those epigraphs is too repetitive: all of them
prominently display the word "Inkscape"... we already know we're
talking about Inkscape! ;) Some of my edits in that area were done to
break that monotone writing (giving a more "human" tone and avoid
repetition of the word "Inkscape").
I'm unsure is this edit was done on purpose or accidentally.
> Sent out another request on the user list for screen recordings...no bites yet. Maybe if someone posted to Deviant Art? Or twitter? Or facebook or flickr or any of those other social websites I don't use... We need the stuff mentioned in this doc: https://docs.google.com/document/pub?id=1QDTbDv7SGZIyrBUvSoraC_587ROY49l-...
Working on it. Commented this before, but haven't had time to record
them. The two drawings that I was going to record are halted.
I'm involved on acourse about web design so will be busy until 23 March.
Regards.
12 years, 2 months
