Hi all,
Bryce , Jon Phillips and I have discussed casually a second IRC meet. Now is a good time. Scribus. 1.2 is done and before we dive into 1.3 we can outline some of our thoughts.
Our tentative time date is 19 Sept 2004 1000 UTC.
Let me know how this works....
Notes and a draft topic list:
http://inkscape.org/cgi-bin/wiki.pl?ScribusInteroperability
Cheers, Peter
I think that we should move the time on that date to 8 AM UTC
Check the time and dates of most of our people: http://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=9&am...
That site above too is a great way to synchronize an international meeting! You can pick the cities people are in and find a reasonable time...amazing!
Jon
On Thu, 2004-09-02 at 18:03, Plinnell wrote:
Hi all,
Bryce , Jon Phillips and I have discussed casually a second IRC meet. Now is a good time. Scribus. 1.2 is done and before we dive into 1.3 we can outline some of our thoughts.
Our tentative time date is 19 Sept 2004 1000 UTC.
Let me know how this works....
Notes and a draft topic list:
http://inkscape.org/cgi-bin/wiki.pl?ScribusInteroperability
Cheers, Peter
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I like the idea of "complementary set of keyboard shortcuts" :)
So,
Here are my proposals for Scribus/Inkscape shortcut unification as well as some random usability notes. Disclaimer: I haven't used Scribus much and may be unaware of some of its capabilities or limitations. This is a "fresh eye" look of a newbie. Disclaimer #2: I'm obviously biased towards Inkscape; feel free to argue if you think some of Inkscape's approaches are unapplicable to Scribus, or if you think Inkscape must borrow something from Scribus and not vice versa. This is only a beginning; if you like this I'll have more :)
All this is based on Scribus 1.2.
== Random usability notes (and one bug)
There are no tooltips on buttons, which makes them hard to figure out.
You have "Grab radius", but you need to also implement "Drag tolerance" as in Inkscape. This means that a mousedrag less than the tolerance pixels is considered a click, not a drag, and does not move an object. I use a tablet with pen instead of a mouse, and with a pen it's very difficult to make a precise click; it's almost always a small drag. So without drag tolerance (4 pixels by default in Inkscape), it's very difficult for me to use Scribus - trying to select something always moves it a bit, very annoying.
"Duplicate" shifts the new object a bit. In Inkscape we decided that it's a bad idea overall, so our Duplicate places the new object exactly over the original.
Consider using more explanations in the statusbar instead of the unhelpful "Ready". For example:
- the number and type of selected objects
- the reasons why some command fails
- explanations for the selected menu item when you go through the menu
- most common functions of Ctrl, Shift, Alt in the current mode, while they are pressed
In "Manage keyboard shortcuts," resizing does not resize the list, only adds empty space to the dialog. Also the size/position of the dialog is not remembered.
Calling e.g. Distribute/Align dialog when less than two objects selected silently fails. It must at least display some explanation in the statusbar. Better yet it must open but have its controls disabled until I select something to align. By the way the dialog is called simply Align, and the Distribute option seems to be always off - why?
Open the Script console. What to do? I type "help". It says, use help() for interactive help. OK, I type "help()". Scribus freezes.
== Most needed keys
Keypad +/- to zoom in/out (even in text edit mode! you have regular +/- for inserting these chars, so keypad ones should be zoom-only)
Middle-drag to scroll canvas
Tab (except in text edit mode) to cycle select through objects
Esc to deselect
== Arrow keys
You have arrow-key movement of objects, but here's how it might be made more rich and Inkscape-like. I think the Inkscape system is logical (again, I'm biased, since I designed most of it myself :)
Without modifiers: move by some predefined amount - this seems to work, but I could not find how to set that amount in prefs
With Shift: move by 10 times the predefined amount (seems to work, but I'm not sure if you use the 10x multiplier)
With Alt: move by 1 pixel at current zoom level - very convenient! (now the same as without modifiers)
With Shift+Alt: move by 10 pixels at current zoom level
With Ctrl: Scroll canvas by some pref-settable amount of pixels, ideally with acceleration as in Inkscape (now it moves the object by some small amount).
== Selector modifiers
The "selector" tool (arrow) would benefit from more Inkscape-like features:
Shift+click to toggle selection; you have it adding to selection, but more useful is to have it add to selection if not selected and remove from selection otherwise
Ctrl+click: select in groups (without ungrouping)
Alt+click: select under (cycles thorough z-order at click point, try Inkscape CVS to see how it works)
Note: ctrl, shift, alt can be combined
Ctrl+drag to rectrict move to hor/vert (this one is very important)
Shift+drag to force rubberband (selection lasso rect) even if starting over an object; add objects within rubberband to selection
Alt+drag to force move of the seleced object no matter where you start the drag
== More default keys in the "Manage keyboard shortcuts":
Shift+Ctrl+s Save as
Shift+Ctrl+d Document setup Shift+Ctrl+a Distribute/align
Shift+Ctrl+f Colors (?) Shift+Ctrl+t Fonts (?)
Raise/Lower/Front/Back: we use PgUp/PgDn/Home/End, but since you are more often in text edit mode where these are motion keys, what about using the same keys but with some modifier (Ctrl, Shift, Alt?)
Show grid/Snap to grid: we enable both with one key, since hardly anyone will need to see a grid without snapping to it. Our key is #, you could use e.g. Ctrl+#.
== Tools
By tools I mean the buttons on the toolbar that starts with the arrow button. Due to the lack of tooltips, I will have to describe which tool I mean instead of using the correct term, for which you'll have to forgive me. These tools are likely to be switched often, so they need keys too (if they already have some keys I could not find them). Here are the keys Inkscape uses for approximately equivalent tools:
"Arrow": F1
"Rectangle": this is a collection of shapes, but since the rect is the default, this would be F4
"Star": Shift+F9, the keypad * key
"Rotate": if you use a separate tool for that, it may be some variation of F1 (e.g. Ctrl+F1)
"Zoom": F3
"Text edit": F8
Other tools might use the remaining F keys with modifiers.
== In text editing
Visual adjustments in text are very convenient with these keys:
Alt+arrows: kern the next char by 1 pixel at the current zoom, both vertically and horizontally (try it in Inkscape to see what I mean)
Alt+>, Alt+< increase/decrease tracking in the current line (or in selection, when we get selection implemented), so it's expanded/contracted by 1 pixel at the current zoom
Ctrl+Alt+>, Ctrl+Alt+< increase/decrease line spacing in the current text object (or in selection), so it's expanded/contracted by 1 pixel at the current zoom
Same keys with Shift act by 10 pixels.
By the way, I could not find a difference between tracking (=letterspacing) and kerning in Scribus (maybe I missed something). In Properties I only see kerning and linespacing but not letterspacing. I know you can select a fragment and "letterspace" it by assigning kerning to it, but it's a bad workaround because it will lose any manual pair kerns that were there. SVG supports both letterspacing ("letter-spacing" CSS property) and kerning (dx/dy attributes on text) independently, and you need to support both if you want to import SVG text properly.
Apologies in advance if some of my comments are repetative, I'm repeating things in case Plinnell has not read them before.
Alt+click: select under (cycles thorough z-order at click point, try Inkscape CVS to see how it works)
note: this combination is widely used by windowmanagers (to drag the window). it was briefly discussed on the inkscape developer list but no better key combination was suggested.
Raise/Lower/Front/Back: we use PgUp/PgDn/Home/End, but since you are
I strongly advise against using Page Up and Page Down for anything other than going up and down the page, it bothers me that Inkscape (and so many other GTK applications) still do it. At the very least they should be combined with a modifier, but I still wouldn't recommend it, as they are awkward to reach keys.
If the keys are available I would recommend Forwards Ctrl+F Backwards Ctrl+B Back Ctrl+Shift+B Front Ctrl+Shift+F
(I'm assuming here that moving back or forward one is the more common action and giving it the easier key board shortcut than sending to the very back or very front)
Alteratively you could use these keybindings Forwards Ctrl+] Backwards Ctrl+[ and make Adobe Photoshop users happy.
It of course makes sense to look at what keybindings are used by Adobe InDesign or Quark Express because those are what your userbase are most likely to be familiar with.
Show grid/Snap to grid: we enable both with one key, since hardly anyone will need to see a grid without snapping to it. Our key is #, you could use e.g. Ctrl+#.
for many users that would be equivalent to Ctrl+Shift+3
== Tools
By tools I mean the buttons on the toolbar that starts with the arrow button. Due to the lack of tooltips, I will have to describe which tool I mean instead of using the correct term, for which you'll have to forgive me. These tools are likely to be switched often, so they need keys too (if they already have some keys I could not find them). Here are the keys Inkscape uses for approximately equivalent tools:
Inkscape inherited these keyboard shortcuts from Sodipodi, they are not necessarily good keybindings. For the Tools in Inkscape I think it would make sense to have single letter keybindings (right under your fingers, eassier to reach than Function keys), but depending on how your text mode is seperated this may not be entirely practical.
I dont know for sure but is possible the keyboard shortcuts were chosen to be similar to ones used by Corel Draw.
"Arrow": F1
This is particularly horrendous, definately goes against the Gnome Guidelines and probably goes against the KDE style guide as most applications use F1 for help.
Other tools might use the remaining F keys with modifiers.
Function keys are awkward enough without adding modifiers. It is impossible to have keybindings for everything so it might be necessary to reconsider any keybindings you have given to features that are not likely to be changed very often.
Raise/Lower/Front/Back: we use PgUp/PgDn/Home/End, but since you are
I strongly advise against using Page Up and Page Down for anything other than going up and down the page, it bothers me that Inkscape (and so many other GTK applications) still do it. At the very least they should be combined with a modifier, but I still wouldn't recommend it, as they are awkward to reach keys.
I don't see how they are "awkward to reach" any more than any other key. And most importantly they're VERY intuitive for the meaning of Raise/Lower/etc - their labels are obvious synonyms of the corresponding functions. I use them subcosciously now, whereas -
Forwards Ctrl+F Backwards Ctrl+B Back Ctrl+Shift+B Front Ctrl+Shift+F
this is what Xara uses, and I _STILL_ have to spend a fraction of a second thinking before I press them when in Xara, even though I've been using Xara for many years. Very unintuitive. And already taken in Inkscape, btw.
Alteratively you could use these keybindings Forwards Ctrl+] Backwards Ctrl+[
Not very intuitive either; these keys may be good for forward/backward but again you need to think before you can map them to the up/down meaning. And they're taken, too.
It of course makes sense to look at what keybindings are used by Adobe InDesign or Quark Express because those are what your userbase are most likely to be familiar with.
Do not forget about Corel Draw and Xara (the two are similar in their keybindings). They have a sizeable following too, and Inkscape is generally closer to them (partly because Sodipodi was modelled on Corel Draw and partly because I've borrowed many things from Xara which is my favorite).
Inkscape inherited these keyboard shortcuts from Sodipodi,
And Sodipodi copied Corel Draw.
For the Tools in Inkscape I think it would make sense to have single letter keybindings (right under your fingers, eassier to reach than Function keys),
In Inkscape you already have them as alternative, see the keys&mouse reference
"Arrow": F1
This is particularly horrendous, definately goes against the Gnome Guidelines and probably goes against the KDE style guide as most applications use F1 for help.
It's logical and very convenient. I use it all the time. There are many other ways to access Help. And as for Scribus, currently it does not use F1 for anything.
Function keys are awkward enough without adding modifiers. It is impossible to have keybindings for everything so it might be necessary to reconsider any keybindings you have given to features that are not likely to be changed very often.
Function keys are for tools. Using a mix of function and non-function keys for tools will be hard to remember. And again, all Inkscape tools have single-letter alternative keys if you prefer.
On Fri, 3 Sep 2004, bulia byak wrote:
Date: Fri, 3 Sep 2004 19:50:50 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: inkscape-devel@lists.sourceforge.net, Plinnell <scribusdocs@...84...> Subject: Re: [Inkscape-devel] Inkscape /Scribus IRC meet
Raise/Lower/Front/Back: we use PgUp/PgDn/Home/End, but since you are
I strongly advise against using Page Up and Page Down for anything other than going up and down the page, it bothers me that Inkscape (and so many other GTK applications) still do it. At the very least they should be combined with a modifier, but I still wouldn't recommend it, as they are awkward to reach keys.
I don't see how they are "awkward to reach" any more than any other
the easiest keys to reach are the home keys asdf and jkl; because that is where hands tend to be on the keyboard. The home keys f and j are particularly easy because most keyboards have notches on those keys allowing you to find them without looking.
the Esc key is easier to hit than any of the Function keys because it is on the top right and isolated, making it relatively easy to hit without looking.
key. And most importantly they're VERY intuitive for the meaning of Raise/Lower/etc - their labels are obvious synonyms of the
But they are EVEN MORE intuitive for scrolling the Page Up and Page Down.
You could just as easily argue that the arrow keys are best choice, but they are already being use for moving on the X and Y axis.
Inkscape is a weird case but in other other GTK applications if Page Up and Page Down are used for something else by default they cannot be rebound to actually go up and down the page, those who dont want it that way have no choice.
corresponding functions. I use them subcosciously now, whereas -
Forwards Ctrl+F Backwards Ctrl+B Back Ctrl+Shift+B Front Ctrl+Shift+F
this is what Xara uses, and I _STILL_ have to spend a fraction of a second thinking before I press them when in Xara, even though I've been using Xara for many years. Very unintuitive.
I think it is a matter of opinion what is best, I think it is unfair to presume that what you prefer is the most obvious or intuitive particularly when you yourself know that your bias is towards keybindings used by Xara.
And already taken in Inkscape, btw.
The keybindings in Inkscape can still be changed, it is not like there has been a version 1.0 release with any implied promise of stability and maintainance.
Inkscape particularly made me understand why trying to have keybindings for everything can be a problem, once a keybinding is set users are reluctant to change to a better one because they are already used to it.
It of course makes sense to look at what keybindings are used by Adobe InDesign or Quark Express because those are what your userbase are most likely to be familiar with.
Do not forget about Corel Draw and Xara (the two are similar in their
I can only assume you meant it makes sense for Inkscape it makes sense to look at those applications (it also makes sense to give greatest weight to Illustrator and Freehand which have the largest user base) because it makes sense for Scribus to look at other Desktop Publishing applications before anything else.
This is particularly horrendous, definately goes against the Gnome Guidelines and probably goes against the KDE style guide as most applications use F1 for help.
It's logical and very convenient.
Logic all depends on your starting point. Again you are being very subjective, convenient is debatable. It is certainly consistant to use Function keys for all the tools, and that is a logical methodology but it doesn't make it more logical than anything else.
The current choice of keybindings is efficient for some (for Corel Draw users most of all) but that does not necessarily make them the best defaults for an application like Inkscape that is willing to make changes to be much more attractive to a wider audience than Sodipodi, and to do things like work within the Gnome Human Interface Guidelines. People using Inkscape very heavily will get used to keybindings but consistant guidelines across the whole desktop works well because means less specific keybindings users have to learn and less confusion when they switch from application. To put it in perspecitive dont you just hate it when command line applications dont follow the style used by GNU applications for command line arguements.
I use it all the time. There are many other ways to access Help. And as for Scribus, currently it does not use F1 for anything.
The tutorials are the closest Inkscape has to help files for now so it is only a minor point, but it will become a glaring inconsistancy if Inkscape is going to try to follow the Gnome Guidelines.
To be fair I can see you are being subjective because I do it myself but hopefully between us we can cancel out our biases and give Inkscape the best keybindings for the majority of users.
Anyway I hope Plinnell will take this on board and be very careful when trying to choose keybindings that will best serve his users.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
the Esc key is easier to hit than any of the Function keys because it is on the top right and isolated, making it relatively easy to hit without looking.
Exactly. And by this measure PgUp/PgDn are easy to reach because they're at the edge of a group of keys and therefore easy to find without looking. And this is also why e.g. function keys are broken into groups, so that each one is either at the edge or close to it.
key. And most importantly they're VERY intuitive for the meaning of Raise/Lower/etc - their labels are obvious synonyms of the
But they are EVEN MORE intuitive for scrolling the Page Up and Page Down.
Sure, but what it we don't need to move by pages, not having any pages in the first place? We have a very isotropic canvas where x/y directions are on the same terms, so the arrow keys with various modifiers are the best for moving the canvas itself or objects on the canvas.
Note that I don't propose that Scribus uses plain PgUp/PgDn for z-order, but with some modifiers. Maybe we can then adopt the same modifiers for these keys too.
this is what Xara uses, and I _STILL_ have to spend a fraction of a second thinking before I press them when in Xara, even though I've been using Xara for many years. Very unintuitive.
I think it is a matter of opinion what is best, I think it is unfair to presume that what you prefer is the most obvious or intuitive particularly when you yourself know that your bias is towards keybindings used by Xara.
Sure, but note that in this case, I'm arguing AGAINST Xara-like bindings :)
And already taken in Inkscape, btw.
The keybindings in Inkscape can still be changed, it is not like there has been a version 1.0 release with any implied promise of stability and maintainance.
No doubt. If you or anyone else proposes a well-thought-out keybindings change (which includes exactly what changes to what, taking into account the entire current keymap) I'll be happy to discuss.
Inkscape particularly made me understand why trying to have keybindings for everything can be a problem, once a keybinding is set users are reluctant to change to a better one because they are already used to it.
Yeah, but rest assured that I will have guts to change it despite user screams - provided you convince me that it's really a change to a BETTER one :)
This is particularly horrendous, definately goes against the Gnome Guidelines and probably goes against the KDE style guide as most applications use F1 for help.
It's logical and very convenient.
Logic all depends on your starting point. Again you are being very subjective, convenient is debatable.
Of course. I'd like to hear from anyone who uses Inkscape heavily and finds F1 for selector inconvenient.
It is certainly consistant to use Function keys for all the tools,
Yes, that's the logic I was referring to. It's the first and most often used tool, and F1 is the first and easiest to reach function key. So they're a natural match.
things like work within the Gnome Human Interface Guidelines. People using Inkscape very heavily will get used to keybindings but consistant guidelines across the whole desktop works well because means less specific keybindings users have to learn and less confusion when they switch from application.
Yes, that's why we're talking about Scribus/Inkscape unification! :)
To put it in perspecitive dont you just hate it when command line applications dont follow the style used by GNU applications for command line arguements.
Sometimes there may be good reasons to provide alternative syntax.
The tutorials are the closest Inkscape has to help files for now so it is only a minor point, but it will become a glaring inconsistancy if Inkscape is going to try to follow the Gnome Guidelines.
F1 for help is good for new users, but they will only need to use it a few times at first. Besides it's unlikely that F1 failure to call Help will really stumble them, since there's a Help menu. On the other hand, F1 as Selector brings lasting benefits for power users :)
Could you all trascribe any and all ideas onto this wiki page:
http://inkscape.org/cgi-bin/wiki.pl?ScribusInteroperability
That way everyone can review and adapt parts of the ideas prior to and during our upcoming 2nd meeting.
Jon
On Sat, 2004-09-04 at 09:04, bulia byak wrote:
the Esc key is easier to hit than any of the Function keys because it is on the top right and isolated, making it relatively easy to hit without looking.
Exactly. And by this measure PgUp/PgDn are easy to reach because they're at the edge of a group of keys and therefore easy to find without looking. And this is also why e.g. function keys are broken into groups, so that each one is either at the edge or close to it.
key. And most importantly they're VERY intuitive for the meaning of Raise/Lower/etc - their labels are obvious synonyms of the
But they are EVEN MORE intuitive for scrolling the Page Up and Page Down.
Sure, but what it we don't need to move by pages, not having any pages in the first place? We have a very isotropic canvas where x/y directions are on the same terms, so the arrow keys with various modifiers are the best for moving the canvas itself or objects on the canvas.
Note that I don't propose that Scribus uses plain PgUp/PgDn for z-order, but with some modifiers. Maybe we can then adopt the same modifiers for these keys too.
this is what Xara uses, and I _STILL_ have to spend a fraction of a second thinking before I press them when in Xara, even though I've been using Xara for many years. Very unintuitive.
I think it is a matter of opinion what is best, I think it is unfair to presume that what you prefer is the most obvious or intuitive particularly when you yourself know that your bias is towards keybindings used by Xara.
Sure, but note that in this case, I'm arguing AGAINST Xara-like bindings :)
And already taken in Inkscape, btw.
The keybindings in Inkscape can still be changed, it is not like there has been a version 1.0 release with any implied promise of stability and maintainance.
No doubt. If you or anyone else proposes a well-thought-out keybindings change (which includes exactly what changes to what, taking into account the entire current keymap) I'll be happy to discuss.
Inkscape particularly made me understand why trying to have keybindings for everything can be a problem, once a keybinding is set users are reluctant to change to a better one because they are already used to it.
Yeah, but rest assured that I will have guts to change it despite user screams - provided you convince me that it's really a change to a BETTER one :)
This is particularly horrendous, definately goes against the Gnome Guidelines and probably goes against the KDE style guide as most applications use F1 for help.
It's logical and very convenient.
Logic all depends on your starting point. Again you are being very subjective, convenient is debatable.
Of course. I'd like to hear from anyone who uses Inkscape heavily and finds F1 for selector inconvenient.
It is certainly consistant to use Function keys for all the tools,
Yes, that's the logic I was referring to. It's the first and most often used tool, and F1 is the first and easiest to reach function key. So they're a natural match.
things like work within the Gnome Human Interface Guidelines. People using Inkscape very heavily will get used to keybindings but consistant guidelines across the whole desktop works well because means less specific keybindings users have to learn and less confusion when they switch from application.
Yes, that's why we're talking about Scribus/Inkscape unification! :)
To put it in perspecitive dont you just hate it when command line applications dont follow the style used by GNU applications for command line arguements.
Sometimes there may be good reasons to provide alternative syntax.
The tutorials are the closest Inkscape has to help files for now so it is only a minor point, but it will become a glaring inconsistancy if Inkscape is going to try to follow the Gnome Guidelines.
F1 for help is good for new users, but they will only need to use it a few times at first. Besides it's unlikely that F1 failure to call Help will really stumble them, since there's a Help menu. On the other hand, F1 as Selector brings lasting benefits for power users :)
This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
Alan Horkan -
bulia byak -
Jon Phillips -
Plinnell