An awful lot of Inkscape's functions (I notice that the new touch selection is another one) seem to be relying on the alt-key being held down and various things done with the mouse. To say that this is a pain under Linux is an understatement since alt-mouse is used by window managers to allow quick manipulation of window sizes and positions, which is vital on large screens. Given that Inkscape is only one app and alt-mouse is effectively in use by every other app on the system for something else, is there any easy way to change these shortcuts to something like meta-mouse or something (anything!) else?
Is it the case that most Inkscape developers are using Windows and are simply not aware of how difficult these alt-mouse shortcuts make it for Linux users?
Thomas Worthington
On 8/3/07, Thomas Worthington wrote:
An awful lot of Inkscape's functions (I notice that the new touch selection is another one) seem to be relying on the alt-key being held down and various things done with the mouse. To say that this is a pain under Linux is an understatement since alt-mouse is used by window managers to allow quick manipulation of window sizes and positions,
Which can be solved by reconfiguring your window manager. I did it a long while ago (using Win key for windows manipulation now) and never came back :)
Alexandre
it´s not wise to rely on this kind of idea.
If we really want to see inkscape on ubuntu soon, then we must think about a way of having it at least compatible with the desktop key bindings.
Or do we expect every single ubuntu user to setup their WM configs in order to use some of the inkscape features?!
Change this now before these shortcuts become "legacy"
JucaBlues
On 8/3/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 8/3/07, Thomas Worthington wrote:
An awful lot of Inkscape's functions (I notice that the new touch selection is another one) seem to be relying on the alt-key being held down and various things done with the mouse. To say that this is a pain under Linux is an understatement since alt-mouse is used by window managers to allow quick manipulation of window sizes and positions,
Which can be solved by reconfiguring your window manager. I did it a long while ago (using Win key for windows manipulation now) and never came back :)
Alexandre
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2007-August-03 , at 13:42 , Felipe Sanches wrote:
it´s not wise to rely on this kind of idea.
If we really want to see inkscape on ubuntu soon, then we must think about a way of having it at least compatible with the desktop key bindings.
Or do we expect every single ubuntu user to setup their WM configs in order to use some of the inkscape features?!
Change this now before these shortcuts become "legacy"
My humble opinion as an occasional linux user is that this kind of messy situation should be fixed at Ubuntu level (or Gnome level, or even FreeDestop level maybe). There should be an official definition with, if possible, a modifier devoted to all global desktop actions (moving windows, opening menus, etc.) keeping the other modifiers free for application level shortcuts. There's simply too few possibilities for an app like Inkscape if the desktop steels some modifiers like Alt or Ctrl. In my (humble, once again) opinion, Inkscape's choice is the right one: rely on Ctrl and Alt (+ combinations with any other key) for application level shortcut and leave Meta (i.e. Windows key) alone. Meta should indeed be the modifier of choice for desktop level actions since it is sledom used in appications currently. Such problems are difficult to solve on Linux, by the very nature of its development model: there is no large entity governing development behind the scene and taking care of the big picture. This is why I wish all the best to projects like FreeDesktop which may make it happen.
JiHO --- http://jo.irisson.free.fr/
Also keep in mind that distros do not write Inkscape manuals.
bob
jiho wrote:
On 2007-August-03 , at 13:42 , Felipe Sanches wrote:
it´s not wise to rely on this kind of idea.
If we really want to see inkscape on ubuntu soon, then we must think about a way of having it at least compatible with the desktop key bindings.
Or do we expect every single ubuntu user to setup their WM configs in order to use some of the inkscape features?!
Change this now before these shortcuts become "legacy"
My humble opinion as an occasional linux user is that this kind of messy situation should be fixed at Ubuntu level (or Gnome level, or even FreeDestop level maybe). There should be an official definition with, if possible, a modifier devoted to all global desktop actions (moving windows, opening menus, etc.) keeping the other modifiers free for application level shortcuts. There's simply too few possibilities for an app like Inkscape if the desktop steels some modifiers like Alt or Ctrl. In my (humble, once again) opinion, Inkscape's choice is the right one: rely on Ctrl and Alt (+ combinations with any other key) for application level shortcut and leave Meta (i.e. Windows key) alone. Meta should indeed be the modifier of choice for desktop level actions since it is sledom used in appications currently. Such problems are difficult to solve on Linux, by the very nature of its development model: there is no large entity governing development behind the scene and taking care of the big picture. This is why I wish all the best to projects like FreeDesktop which may make it happen.
JiHO
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 03 Aug 2007 13:30:30 +0100, jiho <jo.irisson@...400...> wrote:
My humble opinion as an occasional linux user is that this kind of messy situation should be fixed at Ubuntu level (or Gnome level, or even FreeDestop level maybe). There should be an official definition with, if possible, a modifier devoted to all global desktop actions (moving windows, opening menus, etc.) keeping the other modifiers free for application level shortcuts.
Well, it's been the normal method to use Alt for more than a decade; that's as official as it's likely to get.
There's simply too few possibilities for an app like Inkscape if the desktop steels some modifiers like Alt or Ctrl. In my (humble, once again) opinion, Inkscape's choice is the right one: rely on Ctrl and Alt (+ combinations with any other key) for application level shortcut and leave Meta (i.e. Windows key) alone. Meta should indeed be the modifier of choice for desktop level actions since it is sledom used in appications currently.
I don't use a keyboard with a Windows key, not having had a Windows computer for many years I've switched to heavy-duty IBM-PC keyboards. Regardless, I can remap keys but I don't want to for one app.
All that's needed is for the keyboard definition file to allow the assignment of meta instead of alt to the mouse actions. It makes far more sense to allow users to change Inkscape than to require them to change their desktop from the standard layout.
TW
Thomas Worthington wrote:
Well, it's been the normal method to use Alt for more than a decade; that's as official as it's likely to get.
For the record, just because it's been the status quo for so long, that doesn't mean it's the best solution regardless of how "official" it may be.
All that's needed is for the keyboard definition file to allow the assignment of meta instead of alt to the mouse actions. It makes far more sense to allow users to change Inkscape than to require them to change their desktop from the standard layout.
Since that's "all that's needed", please feel free to submit a patch. We'd gladly accept such a patch.
-Josh
On Fri, 2007-08-03 at 07:02 -0700, Josh Andler wrote:
All that's needed is for the keyboard definition file to allow the assignment of meta instead of alt to the mouse actions. It makes far more sense to allow users to change Inkscape than to require them to change their desktop from the standard layout.
I think I'd prefer a preference to use meta rather than alt. That might be more work; I dunno. But I think we only technically have three bits free for modifiers the way it's currently done.
-mental
On Aug 3, 2007, at 10:49 AM, MenTaLguY wrote:
On Fri, 2007-08-03 at 07:02 -0700, Josh Andler wrote:
All that's needed is for the keyboard definition file to allow the assignment of meta instead of alt to the mouse actions. It makes far more sense to allow users to change Inkscape than to require them to change their desktop from the standard layout.
I think I'd prefer a preference to use meta rather than alt. That might be more work; I dunno. But I think we only technically have three bits free for modifiers the way it's currently done.
Though we need to consider things like Mac keyboards and OS X.
:-)
last time I looked at this issue, it seemed that there were a few different things in a few different places that were wrangling keys in different ways. Hopefully we can get them all unified.
On Sat, 25 Aug 2007 04:35:30 +0100, Jon A. Cruz <jon@...18...> wrote:
On Aug 3, 2007, at 10:49 AM, MenTaLguY wrote:
On Fri, 2007-08-03 at 07:02 -0700, Josh Andler wrote:
All that's needed is for the keyboard definition file to allow the assignment of meta instead of alt to the mouse actions. It makes far more sense to allow users to change Inkscape than to require them to change their desktop from the standard layout.
I think I'd prefer a preference to use meta rather than alt. That might be more work; I dunno. But I think we only technically have three bits free for modifiers the way it's currently done.
Though we need to consider things like Mac keyboards and OS X.
:-)
last time I looked at this issue, it seemed that there were a few different things in a few different places that were wrangling keys in different ways. Hopefully we can get them all unified.
I have a patch in the system for this and I did have to put in a central "wrangling point", which is basically a very simple event snooper which sets the Alt flag if the <user selectable (defaults to 1) mod flag> is set. This user setting is a new option in the preferences.xml file so can be set differently by each user for their keyboard rather than being hardcoded in the way the current Alt usage is.
Since the default action of the event snooper is to leave everything alone, it should have no impact on Macs or anyone else who doesn't want to use the option.
I've been using the patch with the SVN version since I wrote it and it seems to be working fine (I'm using Mod3 for my keyboard). As I said in an earlier email, however, I'm not a C++ coder (and after looking at what's involved in fixing the font handling I remember why!) so it's probable that the code could be arranged better but even so the patch is only 146 lines including whitespace and context.
Thomas
On Aug 25, 2007, at 2:48 AM, Thomas Worthington wrote:
I have a patch in the system for this and I did have to put in a central "wrangling point", which is basically a very simple event snooper which sets the Alt flag if the <user selectable (defaults to 1) mod flag> is set. This user setting is a new option in the preferences.xml file so can be set differently by each user for their keyboard rather than being hardcoded in the way the current Alt usage is.
Thanks.
The main question, though, is how the different key modifiers work at different points on different platforms.
Checks probably should be done on Linux, Windows and OS X. Also I know that we might want to check remote X11 and VNC behavior.
Those last three got in the way of certain things in the past, and hid some problems that would show on "normal" platforms.
On Aug 25, 2007, at 10:10 AM, Jon A. Cruz wrote:
Thanks.
The main question, though, is how the different key modifiers work at different points on different platforms.
Checks probably should be done on Linux, Windows and OS X. Also I know that we might want to check remote X11 and VNC behavior.
Those last three got in the way of certain things in the past, and hid some problems that would show on "normal" platforms.
BTW... just to make things "fun", X11 for OS X has the following preference:
[_] Enable keyboard shortcuts under X11 If you select this option, using keyboard shortcuts for menu commands may interfere with X11 applications that use the Meta modifier.
On Sat, 25 Aug 2007 19:26:21 +0100, Jon A. Cruz <jon@...18...> wrote:
On Aug 25, 2007, at 10:10 AM, Jon A. Cruz wrote:
Thanks.
The main question, though, is how the different key modifiers work at different points on different platforms.
Checks probably should be done on Linux, Windows and OS X. Also I know that we might want to check remote X11 and VNC behavior.
Those last three got in the way of certain things in the past, and hid some problems that would show on "normal" platforms.
BTW... just to make things "fun", X11 for OS X has the following preference:
[_] Enable keyboard shortcuts under X11 If you select this option, using keyboard shortcuts for menu commands may interfere with X11 applications that use the Meta modifier.
Again, the patch should not have any effect even then, unless the user has specifically set the "mapalt" option to something other than "1", something a Mac user is unlikely to do, but I suppose could happen if the user has copied their perfs from a Linux box.
"Should" and "Could" are great words, aren't they? If someone else can have a poke at the code I'm happy to work on improving it. But with only a couple of Linux machines I'm not in a position to test the other platforms.
Thomas
On Sat, 25 Aug 2007 18:10:58 +0100, Jon A. Cruz <jon@...18...> wrote:
On Aug 25, 2007, at 2:48 AM, Thomas Worthington wrote:
I have a patch in the system for this and I did have to put in a central "wrangling point", which is basically a very simple event snooper which sets the Alt flag if the <user selectable (defaults to 1) mod flag> is set. This user setting is a new option in the preferences.xml file so can be set differently by each user for their keyboard rather than being hardcoded in the way the current Alt usage is.
Thanks.
The main question, though, is how the different key modifiers work at different points on different platforms.
There's a very good chance it will work, given that all the existing code seems to have the test for GDK_MOD1_MASK hardcoded and the new code simply makes sure that flag is set before ANYTHING else gets to look at the event. That was the main reason I ended up going down that route, the other options were less scary initially, but much harder to maintain in the long run.
Checks probably should be done on Linux, Windows and OS X. Also I know that we might want to check remote X11 and VNC behavior. Those last three got in the way of certain things in the past, and hid some problems that would show on "normal" platforms.
The only one of these I can test is remote X11, which works as expected for me.
But, as I said, the code does nothing by default to how events are handled and unless the option "mapalt" is actually set and set to a value other than "1", the rest of the code "universe" should see exactly what it always has and the hardcoded tests for GDK_MOD1_MASK will work fine. So I'm confident (just as Napoleon was when he left for Moscow).
The only issue I foresee is someone who transfers their prefence file from platform to platform. However, the code is designed so that there is actually only one line that has to be removed to toally deactivate it:
gdk_event_handler_set ((GdkEventFunc)snooper, 0,&snoopunroll);
in sp_main_gui (main.cpp).
If the snooper is not set as the handler then it's never called and can't have any effect other than a little bit of code bloat. So perhaps a #ifdef X11 (assuming such a thing is available) around this would assuage any worries. I don't mean this to be a replacement for testing the code, of course, but perhaps we could at least restrict the code to the platform where it's an issue.
Thomas
On Sat, 2007-08-25 at 19:32 +0100, Thomas Worthington wrote:
If the snooper is not set as the handler then it's never called and can't have any effect other than a little bit of code bloat. So perhaps a #ifdef X11 (assuming such a thing is available) around this would assuage any worries. I don't mean this to be a replacement for testing the code, of course, but perhaps we could at least restrict the code to the platform where it's an issue.
I'd prefer trying it everywhere. Your patch looks like a perfectly reasonable approach to globally remapping the modifiers to me; I just need to give it a final technical review before I merge it (which I plan on doing after I tie off some loose ends with gradient cleanup).
-mental
On Mon, 27 Aug 2007 03:12:35 +0100, MenTaLguY <mental@...3...> wrote:
On Sat, 2007-08-25 at 19:32 +0100, Thomas Worthington wrote:
If the snooper is not set as the handler then it's never called and can't have any effect other than a little bit of code bloat. So perhaps a #ifdef X11 (assuming such a thing is available) around this would assuage any worries. I don't mean this to be a replacement for testing the code, of course, but perhaps we could at least restrict the code to the platform where it's an issue.
I'd prefer trying it everywhere. Your patch looks like a perfectly reasonable approach to globally remapping the modifiers to me; I just need to give it a final technical review before I merge it (which I plan on doing after I tie off some loose ends with gradient cleanup).
Okay, great. I do find that in any event-driven project there comes a time when a custom handler is useful, and it may pay off in future for other purposes.
Thomas
On Fri, 2007-08-03 at 14:10 +0100, Thomas Worthington wrote:
Well, it's been the normal method to use Alt for more than a decade; that's as official as it's likely to get.
What WM in 1997 used alt for dragging windows? I believe Enlightenment was just catching on then... I don't think FVWM used it. I don't believe that it was anywhere near standard at that point.
--Ted
On Fri, 2007-08-03 at 08:42 -0300, Felipe Sanches wrote:
If we really want to see inkscape on ubuntu soon, then we must think about a way of having it at least compatible with the desktop key bindings.
Or do we expect every single ubuntu user to setup their WM configs in order to use some of the inkscape features?!
The Ubuntu team is welcome to ship a patched version of Inkscape if this is their only issue. Seriously, I doubt something like this would stop them. Also, the Ubuntu guys have the flexibility to change the WM defaults -- what makes you think they won't do that? They already adjust them pretty significantly from the GNOME defaults.
--Ted
This problem has been discussed many times before. I think the consensus every time was that it's rather presumptuous for a OS to entirely disable one of the three traditional modifiers entirely for OS's own needs, and that it makes a lot more sense for the OS to change its ways and use the Windows key for moving windows instead.
On 8/3/07, Thomas Worthington <tww@...1737...> wrote:
An awful lot of Inkscape's functions (I notice that the new touch selection is another one) seem to be relying on the alt-key being held down and various things done with the mouse. To say that this is a pain under Linux is an understatement since alt-mouse is used by window managers to allow quick manipulation of window sizes and positions, which is vital on large screens. Given that Inkscape is only one app and alt-mouse is effectively in use by every other app on the system for something else, is there any easy way to change these shortcuts to something like meta-mouse or something (anything!) else?
Is it the case that most Inkscape developers are using Windows and are simply not aware of how difficult these alt-mouse shortcuts make it for Linux users?
Thomas Worthington
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
The attached patch allows the global mapping of any single modifier key to Alt. The default behaviour is to leave Alt as the Alt key.
It adds an option to the preferences file: <group id="options"> <group id="mapalt" value="1" />
Where 'value' can be from 2 to 5 depending on which modifier you want to use instead of Alt (or, 1 to go back to Alt). My machine uses mod3 as the Meta key so I put '3' in here. I have not been able to find a definitive list of which mod values go with Meta/super/hyper etc. so I've left it up to the user to find out which one their machine uses for the key they want to use.
The method I had intended to use was a nightmare due to the separation of the various tool contexts, so I dropped it in favour of a simple event handler (called 'snooper', defined in main.cpp) which steals all the events coming from GDK, remapps the state of the modifier keys if needed and then passes them back on to be handled by gdk_main_do_event. This method is central and requires no changes to the various tool context sources and future developers of tools can continue to use GDK_MOD1_MASK as they do now. Likewise, the user sees all keystrokes and mouse button combinations that use Alt as now using Meta (or whatever they've picked); there's no confusion over keyboard shortcuts still using Alt while the mouse uses Meta or anything like that. It is possible to modify the event snooper to only map mouse combinations but I think a consistant, global mapping is less confusing.
The mapping and snooping are not activated unless the GUI is running.
As I said before, I'm no C++ programmer - this constitutes my second ever venture into C++ after "Hello World" - and there may be better ways to arrange this code, but I think the centralised event snooper is the only way to do it and perhaps having one will be useful for other things in the future. In any case, the maintainance issues of any other approach probably makes it "this way or not at all". If the patch is acceptable, I'd be happy to do up the user documentation.
One thing: I can't work out where the default preferences file is in the source tree, ie, the version that gets installed on a virgin machine. So I've not put the option into it, obviously. But the hardcoded default is to use Alt.
I've been enjoying "selecting under" and node sculpting today, so if nothing else, I'm happy!
Thomas Worthington
This is a resend as the original has not shown up in the list as far as I can see. Apologies if it's dup'ed.
The attached patch allows the global mapping of any single modifier key to Alt. The default behaviour is to leave Alt as the Alt key.
It adds an option to the preferences file: <group id="options"> <group id="mapalt" value="1" />
Where 'value' can be from 2 to 5 depending on which modifier you want to use instead of Alt (or, 1 to go back to Alt). My machine uses mod3 as the Meta key so I put '3' in here. I have not been able to find a definitive list of which mod values go with Meta/super/hyper etc. so I've left it up to the user to find out which one their machine uses for the key they want to use.
The method I had intended to use was a nightmare due to the separation of the various tool contexts, so I dropped it in favour of a simple event handler (called 'snooper', defined in main.cpp) which steals all the events coming from GDK, remapps the state of the modifier keys if needed and then passes them back on to be handled by gdk_main_do_event. This method is central and requires no changes to the various tool context sources and future developers of tools can continue to use GDK_MOD1_MASK as they do now. Likewise, the user sees all keystrokes and mouse button combinations that use Alt as now using Meta (or whatever they've picked); there's no confusion over keyboard shortcuts still using Alt while the mouse uses Meta or anything like that. It is possible to modify the event snooper to only map mouse combinations but I think a consistant, global mapping is less confusing.
The mapping and snooping are not activated unless the GUI is running.
As I said before, I'm no C++ programmer - this constitutes my second ever venture into C++ after "Hello World" - and there may be better ways to arrange this code, but I think the centralised event snooper is the only way to do it and perhaps having one will be useful for other things in the future. In any case, the maintainance issues of any other approach probably makes it "this way or not at all". If the patch is acceptable, I'd be happy to do up the user documentation.
One thing: I can't work out where the default preferences file is in the source tree, ie, the version that gets installed on a virgin machine. So I've not put the option into it, obviously. But the hardcoded default is to use Alt.
I've been enjoying "selecting under" and node sculpting today, so if nothing else, I'm happy!
Thomas Worthington
The patch follows. If this is screwed up it can be downloaded as a text file from
http://www.tww.cx/downloads/mapalt.diff
Index: src/inkscape-private.h =================================================================== --- src/inkscape-private.h (revision 15759) +++ src/inkscape-private.h (working copy) @@ -29,6 +29,9 @@ void inkscape_ref (void); void inkscape_unref (void);
+guint inkscape_mapalt(); +void inkscape_mapalt(guint); + /* * These are meant solely for desktop, document etc. implementations */ Index: src/inkscape.cpp =================================================================== --- src/inkscape.cpp (revision 15759) +++ src/inkscape.cpp (working copy) @@ -117,6 +117,7 @@ gboolean dialogs_toggle; gboolean use_gui; // may want to consider a virtual function // for overriding things like the warning dlg's + guint mapalt; };
struct Inkscape::ApplicationClass { @@ -302,9 +303,10 @@ inkscape->desktops = NULL;
inkscape->dialogs_toggle = TRUE; + + inkscape->mapalt=GDK_MOD1_MASK; }
- static void inkscape_dispose (GObject *object) { @@ -342,13 +344,28 @@
void -inkscape_unref (void) -{ +inkscape_unref (void) { if (inkscape) g_object_unref (G_OBJECT (inkscape)); }
+/* returns the mask of the keyboard modifier to map to Alt, zero if no mapping */ +/* Needs to be a guint because gdktypes.h does not define a 'no-modifier' value */ +guint +inkscape_mapalt() { + return inkscape->mapalt; +}
+/* Sets the keyboard modifer to map to Alt. Zero switches off mapping, as does '1', which is the default */ +void inkscape_mapalt(guint maskvalue) +{ + if(maskvalue<2 || maskvalue> 5 ){ /* MOD5 is the highest defined in gdktypes.h */ + inkscape->mapalt=0; + }else{ + inkscape->mapalt=(GDK_MOD1_MASK << (maskvalue-1)); + } +} + static void inkscape_activate_desktop_private (Inkscape::Application *inkscape, SPDesktop *desktop) { @@ -594,6 +611,12 @@ Inkscape::UI::Dialogs::DebugDialog::getInstance()->captureLogMessages(); }
+ /* Check for global remapping of Alt key */ + if(use_gui) + { + inkscape_mapalt(guint(prefs_get_int_attribute("options.mapalt","value",0))); + } + /* Initialize the extensions */ Inkscape::Extension::init();
Index: src/preferences-skeleton.h =================================================================== --- src/preferences-skeleton.h (revision 15759) +++ src/preferences-skeleton.h (working copy) @@ -175,6 +175,7 @@ " </group>\n" "\n" " <group id="options">\n" +" <group id="mapalt" value="1" />" " <group id="useextinput" value="1" />" " <group id="nudgedistance" value="2"/>\n" " <group id="rotationsnapsperpi" value="12"/>\n" Index: src/main.cpp =================================================================== --- src/main.cpp (revision 15759) +++ src/main.cpp (working copy) @@ -620,6 +620,38 @@ return 0; }
+static void +snooper(GdkEvent *event, gpointer data) { + if(inkscape_mapalt()) /* returns the map of the keyboard modifier to map to Alt, zero if no mapping */ + { + GdkModifierType mapping=(GdkModifierType)inkscape_mapalt(); + switch (event->type) { + case GDK_MOTION_NOTIFY: + if(event->motion.state & mapping) { + event->motion.state|=GDK_MOD1_MASK; + } + break; + case GDK_BUTTON_PRESS: + if(event->button.state & mapping) { + event->button.state|=GDK_MOD1_MASK; + } + break; + case GDK_KEY_PRESS: + if(event->key.state & mapping) { + event->key.state|=GDK_MOD1_MASK; + } + break; + default: + break; + } + } + gtk_main_do_event (event); +} + +void snoopunroll(gpointer data) +{ +} + int sp_main_gui(int argc, char const **argv) { @@ -631,6 +663,8 @@
inkscape_gtk_stock_init();
+ gdk_event_handler_set ((GdkEventFunc)snooper, 0,&snoopunroll); + Inkscape::Debug::log_display_config();
/* Set default icon */
On Mon, 2007-08-13 at 22:03 +0100, Thomas Worthington wrote:
This is a resend as the original has not shown up in the list as far as I can see. Apologies if it's dup'ed.
Could you please put this in the patch tracker and assign it to me (mental), so I can review it for inclusion when I have time? Patches tend get lost on the mailing list.
-mental
participants (10)
-
Alexandre Prokoudine -
Bob Jamison -
bulia byak -
Felipe Sanches -
jiho -
Jon A. Cruz -
Josh Andler -
MenTaLguY -
Ted Gould -
Thomas Worthington