Created a branch?
by Diederik van Lierop
Apparently I created a branch in our svn repository by mistake, I only
intended to switch to another revision. I was using eclipse without
paying much attention to which popup menus I was exactly in.
See rev. #20751, we now have a trunk in our trunk :-(. Could someone
please delete this? I'm not going to try to do this myself to avoid
making even a bigger mess of it. I'm not very familiar with this stuff.
Sorry.
Diederik
12 years, 2 months
error compile svn revision 20749
by Valessio Brito
mv -f $depbase.Tpo $depbase.Po
depbase=`echo widgets/gradient-toolbar.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread
-DORBIT2=1 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1
-I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT
-I/usr/include/poppler/glib -I/usr/include/poppler
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread
-I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include
-I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
-I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4
-I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6
-I/usr/include/atk-1.0 -I/usr/include/libxml2
-I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc
-I./bind/javainc/linux -Werror=format-security -Wall -Wformat
-Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith
-Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch
-Wno-unused-parameter -g -O2 -fopenmp -MT widgets/gradient-toolbar.o
-MD -MP -MF $depbase.Tpo -c -o widgets/gradient-toolbar.o
widgets/gradient-toolbar.cpp &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo widgets/gradient-vector.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread
-DORBIT2=1 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1
-I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT
-I/usr/include/poppler/glib -I/usr/include/poppler
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread
-I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include
-I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
-I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4
-I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6
-I/usr/include/atk-1.0 -I/usr/include/libxml2
-I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc
-I./bind/javainc/linux -Werror=format-security -Wall -Wformat
-Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith
-Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch
-Wno-unused-parameter -g -O2 -fopenmp -MT widgets/gradient-vector.o
-MD -MP -MF $depbase.Tpo -c -o widgets/gradient-vector.o
widgets/gradient-vector.cpp &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo widgets/icon.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/freetype2 -pthread
-DORBIT2=1 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libwpg-0.1
-I/usr/include/libwpd-0.8 -I/usr/include/poppler -D_REENTRANT
-I/usr/include/poppler/glib -I/usr/include/poppler
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -DPOTRACE=\"potrace\" -D_REENTRANT -pthread
-I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include
-I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
-I/usr/include/pangomm-1.4 -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2
-I/usr/include/directfb -I/usr/include/libpng12
-I/usr/include/pixman-1 -I/usr/include/gtkmm-2.4
-I/usr/lib/gtkmm-2.4/include -I/usr/include/atkmm-1.6
-I/usr/include/atk-1.0 -I/usr/include/libxml2
-I/usr/include/gtkspell-2.0 -I../cxxtest -I./bind/javainc
-I./bind/javainc/linux -Werror=format-security -Wall -Wformat
-Wformat-security -W -D_FORTIFY_SOURCE=2 -Wpointer-arith
-Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch
-Wno-unused-parameter -g -O2 -fopenmp -MT widgets/icon.o -MD -MP -MF
$depbase.Tpo -c -o widgets/icon.o widgets/icon.cpp &&\
mv -f $depbase.Tpo $depbase.Po
widgets/icon.cpp: In function 'void sp_icon_fetch_pixbuf(SPIcon*)':
widgets/icon.cpp:227: error: 'gtk_icon_theme_get_default' was not
declared in this scope
widgets/icon.cpp:228: error: 'GtkIconLookupFlags' was not declared in this scope
widgets/icon.cpp:228: error: 'gtk_icon_theme_load_icon' was not
declared in this scope
widgets/icon.cpp: In function 'bool prerender_icon(const gchar*,
GtkIconSize, unsigned int)':
widgets/icon.cpp:946: error: 'gtk_icon_theme_get_default' was not
declared in this scope
widgets/icon.cpp:947: error: 'GtkIconLookupFlags' was not declared in this scope
widgets/icon.cpp:947: error: 'gtk_icon_theme_load_icon' was not
declared in this scope
make[2]: ** [widgets/icon.o] Erro 1
make[2]: exit... `.../inkscape/src'
make[1]: ** [all-recursive] Erro 1
make[1]: exit... `.../inkscape'
make: ** [all] Erro 2
12 years, 2 months
Bizarro Makefile_insert usage
by Krzysztof Kosiński
What is the purpose of using Makefile_insert to pretend that everything is in
the src directory instead of using the SUBDIRS directive?
I'm intending to change the Automake build system to link the executables
from single object files instead of static libraries so that we may finally
put files in the proper directories (e.g. remove widgets/ and dialogs/ and
move those to ui/widget and ui/dialog/, as well as join helper/, util/ and
svg/), and I would like to know whether I should also sanitize general
Makefile usage while I'm at it.
Regards, Krzysztof Kosiński
--
View this message in context: http://www.nabble.com/Bizarro-Makefile_insert-usage-tp22120462p22120462.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
12 years, 2 months
Re: [Inkscape-devel] Corel DRAW-like Snapping
by Diederik van Lierop
Op Ma, 16 februari, 2009 01:47, schreef Krzysztof KosiÅski:
>
>
> Diederik van Lierop wrote:
>>
>> Already implemented. Please select "only snap the node closest ..." in
>> the prefs.
>>
> This is great! Why isn't it on the snapping toolbar though? I didn't find
> it
> at first because I assumed that most of the snapping options will be on
> the
I didn't want to put everything in the toolbar, because that would be way
too much. Currently only the per-document snapping options are in the snap
toolbar, and the prefs are not. Maybe we could just add a button to
quickly open the preferences dialog, defaulting to the snapping tab? That
would make them more easy to discover.
> toolbar. Also of note is that the snapping options from the toolbar are
> not
> present in the prefs dialog - not very intuitive if e.g. someone disables
> the toolbar to conserve screen space like I do.
They used to be available in the document properties dialog, but it was
difficult not make a mess of it using only checkboxes. Now we've got
icons, we could use these in the document properties dialog too, but I do
not like duplicating functionality (and code) unless really badly needed.
> Another thing is that the visualization of the snapping isn't best - while
> hovering over e.g. a rectangle, there is no indication of which node will
> snap when I drag the rectangle - it only appears when I start dragging,
> and
> it isn't clear what this little circle means.
We could indeed use some better graphics here, I just chose one from
stock. The cross (displayed after snapping) is not very noticeable either.
> The best thing to do would be
> to display text over the node that will snap (e.g. "corner", "midpoint",
> etc.) while the user hovers the select tool over the selected shape, and a
> similar text when
I think text would be a bit too intrusive, but it would indeed be useful
to display what will snap in advance.
> However, those are just small usability glitches. Again, thanks for this
> incredible feature!
Thanks. You're welcome!
Regards,
Diederik
12 years, 2 months
Inkscape + Boost == usage question
by Milosz Derezynski
Hey guys,
In the course of doing the work in cooperation with LinuxFund, one question:
Can I fully depend on boost?
Regards
M.
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
12 years, 2 months
Typo in current svn - src/helper/sp-marshal.cpp
by Lucas Vieites
Hi, I'm trying to compile from svn and while doing "make" it
complained about not finidng a file.
I think I've found a typo in "src/helper/sp-marshal.cpp".
On the first line it says:
============================
#include "helperosp-marshal.h"
============================
but should be:
============================
#include "helper/sp-marshal.h"
============================
Cheers,
--
Lucas Vieites <lucas@...1852...>
12 years, 2 months
Idea: Get rid of some .h files by using static signal binding
by Krzysztof Kosiński
Right now every dialog, extension, etc. has to have a header file - otherwise
it's unusable. The underlying issue for dialogs is that there must be an
action defined to open them. This means either including the dialog header
in verbs.cpp, or wherever the dialog is used. I stumbled over OpenBabel
sources some time ago and this gave me the following idea. We put this in
some file, e.g. action-manager.h:
class ActionManager {
...
typedef ActionVector std::vector<Glib::RefPtr<Gtk::Action> >;
class GetActionsMarshaller {
...
bool marshal(InType x) {
_actions.push_back(x);
}
OutType value() { return _actions; }
ActionVector _actions;
}
...
static ActionManager *get() {
static ActionManager *am = new ActionManager();
return am;
}
Glib::RefPtr<Gtk::ActionGroup> get_document_action_group(Glib::ustring
name) {
Glib::RefPtr<Gtk::ActionGroup> ag = Gtk::ActionGroup::create(name);
ActionVector actions = signal_get_actions.emit();
for(ActionVector::iterator i = actions.begin(); i != actions.end(); ++i)
{
ag.add(*i);
}
return ag;
}
sigc::signal<Glib::RefPtr<Gtk::Action>, GetActionsMarshaller>
signal_get_actions;
friend class GetActionsMarshaller;
};
template<typename T>
class ActionManagerEntry {
ActionManagerEntry() {
ActionManager::get()->signal_get_actions.bind(sigc::ptr_fun(T::create));
}
};
Then in the dialog file we put this:
class ShowSomeDialogAction : public Gtk::Action {
...
virtual void on_activate() {
SomeDialog::show();
}
static Glib::RefPtr<Gtk::Action> create() {
return Glib::RefPtr<Gtk::Action>(new ShowSomeDialogAction);
}
}
ActionManagerEntry<ShowSomeDialog> ame_show_some_dialog;
And to construct the action group we do this:
ActionManager *am = ActionManager::get();
Glib::RefPtr<Gtk::ActionGroup> document_actions =
am->get_document_action_group(document_name);
What happens here: Each ActionManagerEntry adds a callback to the
ActionManager object. This way, the actions are not actually created until
GTK is initialized and a document is opened. When we want to create an
action group for a document, we send the get_actions signal. The
GetActionsMarshaller class marshals the responses we get from the registered
callbacks and creates a vector of actions, which are then added to an action
group and returned. A similar approach can also be used to get rid of
headers and centralized initialization for e.g. extensions
What do you think of this approach? On one hand, it scatters the action
definitions across many files, but on the other it removes the need for
centralized initialization and improves modularity (everything pertaining to
a given dialog is in one file, including its actions).
Regards, Krzysztof Kosiński
--
View this message in context: http://www.nabble.com/Idea%3A-Get-rid-of-some-.h-files-by-using-static-si...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
12 years, 2 months
Generic cascading in libcroco
by Robert Staudinger
Hello,
I've finally gotten around to add a generic interface to the libcroco
selection engine. Pretty much just exchanging libxml calls to
invocations on an vtable provided by the API consumer.
On top of that I reinstated the libxml-based API and made sure the
tests (the selection engine is only used by test5) work as before.
Are you inkscapers still interested in eventually using upstream
libcroco? Your internal copy seems to have deviated pretty much from
upstream, it would be good if we could at least exchange fixes, things
were not quite obvious looking at the raw rdiff. We (Thomas Wood +
yours truly) actually tried to extract just the selection engine
patch(es) from your svn repository, but it proved quite hard to make
any sense of it.
My branch is at
http://bzr-playground.gnome.org/~robsta/libccss-selection-engine/
but will go to trunk within the next few days, as the tests already
work as they should.
Best,
Rob
12 years, 2 months
cruft in prefs
by bulia byak
The "Latency skew" and "Pre-render named icons" options make
absolutely zero sense for the user.
Especially the former. For the latter, I can at least guess that it's
something to do with icons. With "skew", I'm totally at a loss. What
latency? Where? When? Tooltip only exacerbates the confusion.
Can we please remove them and never, never again add such "options for
the developers" to the UI?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12 years, 2 months
