Adaptable UI problems
by Krzysztof Kosiński
I have some doubts about the adaptable UI feature.
Part 1: UI issues
- The UI mode selection combo box (called "Task" for some reason) has
usability problems: 1. it jumps around when changing mode, so every
time I change it, I have to find it again to try another mode; 2. when
the main commands toolbar is vertical, it causes a very large
horizontal padding on it, even when it's hidden in the overflow menu.
- Tearing off toolbars does not adjust their size to fit the controls.
If I tear off a toolbar from a small window, I get a toolbar with an
overflow menu. If I tear off from a maximized window, I get a toolbar
with lots of unused space. This makes tearing off highly useless.
- Toolbars can be torn off but can't be attached in a location
different that the original one. This is because they use
GtkHandleBox, for which the docking position is fixed. At the same
time GDL has a widget named GdlDockBar which sounds like a true
dockable toolbar (but it might as well be something else, I don't
know).
Part 2: UxManager class
- UxManager::setTask: Magic constants in switch.
- UxManager constructor: "tags" is created but doesn't do anything.
- What is the point of having several desktops attached to one UxManager?
Part 3: util/ege-tags.h, util/ege-tags.cpp
- ege-tags.h: It supposedly implements
http://create.freedesktop.org/wiki/ResourceTagging but at present I
don't see any place in Inkscape that could make use of tagging.
- Even if the aforementioned specification was good, the UxManager
class apparently tries to do two completely unrelated things: manage
external resources and change the UI mode.
- TagSet: if I understand correctly what this class attempts to do, it
should use std::tr1::unordered_map<Tag, int> with appropriate hash and
equality predicates instead of the combination of std::vector<Tag> and
std::map<std::string, int>.
Part 4: other problems
- toolbox.cpp:1578: code related to changing the UI layout uses a
switch to assign function pointers. Polymorphism should be used
instead.
Regards, Krzysztof
13 years, 8 months
GSoC Entry - Inkscape Web Exporter
by Alex Trujillo
Hey folks. I've been using Inkscape for years, and I couldn't think of a
better project to join for my first GSoC. I've written up a proposal on an
exporter of vector graphics for various web standards. I have experience
using those various web standards over the years, most of which are
documented on Google Code. I just wanted to run this by you guys before I
submitted it, since I've read something to the tune that some of the best
proposals have come from those who have sought community support.
Here's the link to the proposal on Google Docs (as a public document)
http://docs.google.com/Doc?docid=0AcePN-K69iVuZDI2ajlmYl85MjhjaHhyYnhndw&...
Nanoblok is a project I've been working on my own for a while:
http://code.google.com/p/nanoblok/
My personal website, where I have a great deal of graphics I've made in
Inkscape:
http://infokraft.org/
I even have an Inkscape tutorial on there I did not too long ago!
Well, please lend me your questions and comments!
- Alex
13 years, 8 months
Re: [Inkscape-devel] Filter effect and blur background
by Jasper van de Gronde
(This is regarding "discontinuities" appearing in blurs, when using
BackgroundImage.)
Ivan Louette wrote:
> Thanks Jasper !
>
> Try Yann's file I sent back ; it breaks some times and sometimes not...
>
> ivan
I have indeed been able to reproduce the problem, and found a few
copy-paste bugs in Gaussian blur (which normally wouldn't be triggered,
and as such went unnoticed) in the process. But the real problem seems
to be with the way in which the background image is accessed. In essence
the background image doesn't take the area enlargement into account that
is needed to correctly render the blur.
To properly fix this would probably require a few more changes than I'm
comfortable with at this stage in the release cycle, and could take a
while anyway, so I've filed a bug (+associated rendering test):
https://bugs.launchpad.net/inkscape/+bug/554649
13 years, 8 months
Re: [Inkscape-devel] GSoC - transformation anchors - before apply
by Zhenfeng Zhao
Hello,
Thank you for all feedback a few days ago. I basically have some
understanding about the project, which may allow me to start the proposal.
In this weekend, I will write a proposal for the project, "Transformation
anchors", with all information that I have got, and my ideas in planning.
Should I submit it or send it to the mailing list for some feedback first?
I will put some responses below...
On Fri, Mar 26, 2010 at 8:01 PM, <
inkscape-devel-request(a)lists.sourceforge.net> wrote:
------------------------------
>
> Message: 4
> Date: Fri, 26 Mar 2010 20:18:02 +0100
> From: Pajarico <pajarico@...400...>
> Subject: Re: [Inkscape-devel] GSoC - transformation anchors - before
> apply
> To: inkscape-devel(a)lists.sourceforge.net
> Message-ID:
> <ad4dc3fc1003261218k7b012d82o5b3d93308cfdcab5@...401...>
> Content-Type: text/plain; charset=UTF-8
>
> Hi, I'm the author of the specification.
>
@Z. Zhao
> > I am interested in working on the "transformation-anchors" project in
> GSOC this year.
>
> Good to hear! Welcome. If something on the spec is not clear just ask
> on this mailing list. I'm not a coder but I might be able to help you.
> I have the original SVG files of the GUI mock-up in case you want to
> play with them.
>
>
Hello Pajarico,
It is a pleasure hearing from you. I would love to play with SVG files and
GUI mock-up that you have. It would be great, if you can share them with me.
Thank you.
> For your consideration: there are two other projects related to this one:
> * 1) adjust origin of coordinates of document
> * 2) allow math operations (like sum, substraction, multiplication,
> division) inside the spin boxes for Height, Width, X, Y; and now I
> would add center of transformations.
> Doing everything in just one run might be too much but try to keep them in
> mind.
>
>
>
These projects seem very relevant. I definitely will consider them into the
plan. I see the possibility to work on these after completing the
transformation anchor project, perhaps one or both of them. If there is no
time to finish all of these in three months, I will try to make sure
on-going work is easy to do. After the three months of work, I may be
interested to continue the work, if I have time.
Basically, I will do some planning that includes all these relevant tasks.
At some point later, it may become clear what can be done.
> ------------------------------
>
> Message: 5
> Date: Fri, 26 Mar 2010 23:09:30 +0300
> From: Alexandre Prokoudine <alexandre.prokoudine@...400...>
>
> On 3/26/10, Pajarico wrote:
>
> > * 2) allow math operations (like sum, substraction, multiplication,
> > division) inside the spin boxes for Height, Width, X, Y; and now I
> > would add center of transformations.
>
> Just steal code from GIMP 2.7.0+ :)
>
> Alexandre
>
>
Cool. I guess I can do that. Stealing from open source is something that I
have done for many times, both for Master thesis and at-work programs.
Recently, I took some code for spline interpolations into my thesis. Taking
code from Gimp should not be too difficult to me. Translating it into C++ is
doable too. I do porting of different languages on daily bases.
Regards,
Zhenfeng.
13 years, 8 months
XDG User Dirs
by Krzysztof Kosiński
Hello
While taking a stab at fixing the command line on Windows, I can also
implement the XDG User Dirs specification, using relevant GLib
functions. However, there is a slight problem with this: we currently
look for user data (palettes, extensions, etc.) in the user's config
directory, not in the data directory. The default user config
directory on Unix is ~/.config, while the default user data directory
is ~/.local/share.
Is it OK to look in .local/share? We can automatically create a README
in the config directory on the first run that tells the user to move
his datafiles to ~/.local/share/inkscape.
Regards, Krzysztof
13 years, 8 months
New memebr and a bug (maybe)
by CoD
Hello, I'm a 31 years old developer from Italy and I've been using
Inkscape for years.
I've just subscribed to this mailing list and.. yeah... I'm already here
with a bug report :P
Recently I experienced a strange behaviour with KDE 4 preview system and
svg/svgz files saved with the last version of inkscape (both stable and
devel version) so I decided to contact you.
I hate duplicate/unclear bug reports so I would like to discuss this
thing a bit with you before filing a bug to launchpad.
So, let's try to explain what I've found
System: Kubuntu 9.10 with KDE 4.3.2
Inkscape: devel version and 0.46 (See below)
Reproducible: yes
These are the steps I did:
1) I drew a simple icon with inkscape (a circle and a polygon)
2) I save it as svg or svgz (get the file here [1])
3) The preview on my kubuntu 9.10 looks crazy (get the preview here [2])
as if nodes position has been screwed
4) I open the svg file with Inkscape 0.46
5) I change the color of an element and save again
6) The preview still looks crazy
7) I open the file again with Inkscape 0.46 but this time I move the
polygon around, then I place it in the old position and save
8) The preview looks perfect, as if nodes position has been restored (get
the file and the preview here [3][4])
I can't really understand what's going on here but seems that KDE 4 has
troubles when previewing svg/svgz files saved with inkscape > 0.46
This happens also using ksvgtopng to convert an svg file to a png
Could this possibly be related to bug 170049 [5] ?
If you need more experiments just ask :-)
Thank you
Claudio Canavese (CoD)
1: http://cod-web.net/inkscape/devel.svgz
2: http://cod-web.net/inkscape/devel.png
3: http://cod-web.net/inkscape/046.svgz
4: http://cod-web.net/inkscape/046.png
5: https://bugs.launchpad.net/inkscape/+bug/170049
13 years, 8 months
Curve Sketching
by Ilya Baran
Hi,
I've developed an algorithm for fitting smooth curves (the curves are
like in Spiro, but piecewise-linear curvature) to user sketches. I'm
thinking that this could be useful in Inkscape as a replacement or
alternative to the current pencil tool algorithm. Compared to
existing stuff, the benefit is that the curves are usually much nicer,
the drawback is that it's a complicated algorithm and is
slower--fitting a curve of moderate complexity will likely take about
1 second.
Would the Inkscape devs be potentially interested in including this
functionality? I'm looking into rewriting my research prototype to be
faster, cleaner, more robust, and to remove proprietary dependencies.
I can write the library that does the fitting, but I'm unfamiliar with
Inkscape's code base, so I'd need help integrating it in. The time
frame is that I'd likely be done with the library by the middle of
summer.
My paper with details and comparisons to existing methods (including
Inkscape) at the end is at http://www.mit.edu/~ibaran/curves/ The
reported timings can probably be improved by close to a factor of 2.
Thanks,
-Ilya
13 years, 8 months
