fenv.h, fmin, fmax
by Jeremy C. Reed
Using inkscape-21256 snapshot (because release version has bug causing
core dump when attempting to change fill color as reported numerous
times).
src/display/nr-arena-shape.cpp has
#include <fenv.h>
But I don't see any use of floating-point definitions,
FE* macros, or fe*() functions.
I commented that line out and inkscape built fine. (Also some platforms
don't have any fenv.h.)
Also src/live_effects/lpe-dynastroke.cpp uses fmin and fmax.
Some platforms don't have that. So I added to
src/live_effects/lpe-dynastroke.cpp :
#define fmin(a,b) ((a)<(b)?(a):(b))
#define fmax(a,b) ((a)>(b)?(a):(b))
Also work/inkscape-21256/src/display/nr-filter.cpp refers to fmax but it
is commented out.
13 years, 12 months
LPEs for 0.47, take two
by Alexandre Prokoudine
Hi,
Could we possibly try to include two currently disabled LPEs into
0.47? I'm particularly talking about:
1. Mirror symmetrically, which resolves multiple times requested
symmetric drawing mode
2. Booloops, which makes Spiro a lot more useful.
For now I moved all entries for currently disabled LPEs and the LPE
tool itself from POTFILES.in to a newly created POTFILES.ignore so
that translators have less problems.
Alexandre
14 years
LPE Effects: Red line
by Tavmjong Bah
Hi,
The editable red line showing the original path in an LPE when the LPE
path is selected and the Node tool in use is no longer present in 0.46
+svn. Is this by design or is this a bug? I found it quite useful to be
able to manipulate the original path and see the effect on the LPE path.
Tav
14 years
pedro
by Alexandre Prokoudine
Hi,
Before we hit strings freeze, it would be great to do something about
Pedro (XMPP client). I know that this feature is by no means complete
and is supposed to be rewritten more or less from scratch, but what we
have currently is something optional that is always in English. In my
not very humble opinion even such a feature should be localized.
Keeping something that is not ready but somewhat available
unlocalizable intentionally doesn't really sound wise to me. Could we
please have this fixed?
Another thing is that some messages are actually marked for
translation and don't work. So I'm tempted to move them to
POTFILES.ignore, because they don't make any sense to translator at
the moment: even if they rebuild Inkscape with --enable-inkboard they
can't even check what it looks like.
Alexandre
14 years
Reducing the number of control/tool bars
by JiHO
Hi everyone,
With the new snap control bar, Inkscape is becoming quite plump above
the waist. Combined with labels that are longer in many other
languages than they are in english, this does not leave very much
space to draw in the end. See this example in french on a 1280*800
display (i.e. not the smallest around)
http://dl.getdropbox.com/u/1047321/inkscape/fat_ui.png
The width is about half-drawing/half-palette, and, more importantly,
the height cannot even accommodate all the tools even in this fully
maximized setting.
The snap control bar is not very wide but control bars do not seem to
be dockable one next to each other. They apparently need to be on top
of each other. Is that specific to my version of GTK or a known
limitation?
Now my real questions: what do you think about removing some of the
toolbar items and reducing the number of control bars to two, as
before? Do we really need buttons for new document, save, print, etc.
when all of them are readily available in the menu and have standard,
well known keyboard shortcuts? Having the snap controls in the toolbar
make sense because the expose functionality that is more difficult to
get to otherwise. But for the rest...
My opinion would be:
item status why?
new remove present just a cm above, in the file menu; well known
shortcut
open remove idem
save remove idem
print remove idem + less frequently used
import ?
export ?
undo remove present to reach in the edit menu; very well known shortcut
redo remove idem
copy remove idem
cut remove idem
paste remove idem
zoom
.
.
align keep it is inkscape specific
except maybe:
layers ? there is the layers' dropdown already for easy access
global prefs remove if users really need to get to the global
preferences often enough that it requires a button here, it's probably
that there is a deeper problem. Plus this would reduce the confusion
between the two because of their very similar icons (as was mentioned
earlier on the list).
doc. prefs keep
Removing that would make enough room to fit the snap bar next to the
main control bar. If GTK can't do it dynamically, it would need to be
hardcoded, for now.
These changes might seem to be at the detriment of beginners, but once
again they target:
- functions that are similar in most software, so for which the
keyboard shortcuts are easier and more efficient to learn
- functions that are easily available in the menu. Navigating to a
menu is not that tedious especially when the menu is just a few pixels
above the tool bar button.
I looks like a bad habit carried over from some windows programs
rather than like a real design decision on the part of the linux
desktops.
Plus, other apps (like the gimp) don't have buttons for such things
and I haven't heard anyone complaining (about that part of the UI at
least ;) )
I hope it is not too late to mention that. I think if change ever
happens, it should be before 0.47, before people get exposed and used
to a more cluttered UI.
Thanks in advance for your comments.
JiHO
---
http://jo.irisson.free.fr/
14 years
Interface buglets
by Tavmjong Bah
Hi,
Here are a few interface buglets in 0.46+svn:
1. "Duplicate Current Layer..." has "..." but doesn't open a dialog.
2. Icons for flipping/rotating are not being taken from icons.svg.
3. "Extensions" sub-menu items still use "Effects".
4. "Guide around page" should be "Guide Around Page" for consistency.
5. "Display Mode" radio buttons are not updated if one uses "Toggle".
6. "Display Mode->Toggle" only toggles between "Normal" and "Outline,
this isn't very clear from the menu.
Tav
14 years
