Inkscape doesn't respond to Ctrl-Ins, Shift-Ins, Shift-Del

[Bug Importer]

The following key combinations should work:
Ctrl-Ins: Copy
Shift-Ins: Paste
Shift-Del: Cut
Like in all other programs. Using editing keys is an automatism and if one
application responds to them differently... (Especially problematic is
Shift-Del as this currently appears to delete text rather than cut it.)

[nightrow (jb-benoit)]

i think this was discuss elsewhere (can't find where), and it seems that the only shortcut implemented are the "new ones", like ctrl-C for copy, Ctrl-v for paste.
The "old" shortcuts you mentionned are thus not planned to be implemented (if 'im not wrong)
As i'm not sure, waiting for someone with the knowledge to set this bug status to "invalid" if needed.

[Ryan Lerch (ryanlerch)]

inkscape keys can be mapped... if you want these keys to do these functions add the following lines to inkscape directory/share/keys/default.xml

  <bind key="Delete" modifiers="Shift" action="EditCut"/>
  <bind key="Insert" modifiers="Shift" action="EditPaste"/>
  <bind key="Insert" modifiers="Ctrl" action="EditCopy"/>

whether or not inkscape's default keys should be shipped with these mappings is open for discussion...

[anatoly techtonik (techtonik)]

I bet all arguments are already said. I can only add +1 to discussion. I feel awkward working with text in Inkscape.

[Peter Hendrix (inkscape-d)]

Bug is confirmed, but... will it be resolved? I see it has been open for a very long time.

[jazzynico (jazzynico)]

Fixed in the trunk, revision 12161.

[jazzynico (jazzynico)]

Just a reminder to update the Keys and mouse reference.

[jazzynico (jazzynico)]

Shortcut added in inkscape-docs, revision 492.

[anatoly techtonik (techtonik)]

Awesome! Which version will it be? The Inkscape 0.91 "0.91" milestone seems strange.

[jazzynico (jazzynico)]

@techtonik - 0.91 is the next Inkscape version (no release date yet). We published an article on the Inkscape website last December about the version numbering:

"The topic of version numbering has been discussed many times over the years. The original version numbering scheme was tied to our goal of having full support for the SVG 1.0 standard. We've decided that it was time to change it to better reflect it's maturity as a vector graphics editor instead.

We still have other objectives that we would like to complete prior to releasing 1.0, but this is a way for us to get moving forward on that path."

[Hachmann (marenhachmann)]

Closing this bug now for the inkscape website, as it's content related. If this is wrong in your opinion, please tell us about it.

[jazzynico (jazzynico)]

IMHO the report affects the inkscape website because its published documentation regarding shortcuts is outdated. Thus it's just a reminder to update it as soon as 0.91 is out.

[Hachmann (marenhachmann)]

How about if I compile all of the 0.91 content update related reports together into a single bug report?

[Martin Owens (doctormo)]

@jazzy - the inkscape documentation bugs are making the code bugs for the website hard to manage. So we need a separation between the inkscape-web project and the content of said website which doesn't get committed to the website code base any more.

It might be good to have a #website tag and keep the reports in inkscape-docs, then we can point people to easy bugs for content on the website or easy bugs for code for the website without the two mixing too much.

[jazzynico (jazzynico)]

> So we need a separation between the inkscape-web project and the content of said website which doesn't get committed to the website code base any more.

That's a huge issue for me. The current documentation (tutorial, keys and mouse reference) is translated via PO files and generated independently from the website. Not being able to update the site with the generated content is a regression IMHO.

I understand that for many reasons it is not easy to maintain that way (from a webmaster point of view), but since we don't have tools to ease translation work, I really don't see how we could do. And as for the tutorials, they also need to be synchronized with the SVG versions embedded in the application.

But maybe we don't want that kind of documentation in the new website anymore? The tutorials and K&M reference are in the application already. We could link the K&M reference to the appropriate help menu and remove everything from the website if it's more convenient.
Still looking for an elegant solution for that issue...

[Hachmann (marenhachmann)]

It's good to hear that all docs are now also available for using inkscape offline :-D

I think that the docs should also stay available on the website, and be kept current, because users might want to see how it works before they install the software (I would be that kind of user) and also because it shows how much work has gone into good documentation to an interested person.

The (outdated) docs are currently on the website, and there are several links to them (esp. the tutorials). My naive question would then be: Couldn't we 'just' mirror the relevant parts of inkscape-docs automatically (and hope that the file names always stay the same)?

[Martin Owens (doctormo)]

The code for making the docs available is already complete and the docs directory currently compiled on live has been placed there manually. The outstanding issue of updating the document files is a problem, but that requires an inkscape-web bug which specifies it as a code or sys-admin problem and not a content problem.

Does this make sense?

[Hachmann (marenhachmann)]

To me, yes. That's what I intended with the compilation ;-) (" Need regular documentation updates" and then specifying for what exactly)

[Hachmann (marenhachmann)]

Okay, that was indeed naive. Making the docs depends even on non-free Java... (is this still true?) and inkscape and saxon...

Is it possible to set bzr ignore differently for different branches of the same project?

Then there could be another branch (for example "stable-web") in inkscape-docs with the finished docs in their corresponding directories, which gets the necessary bugfixes for the currently released inkscape version.
One would only have to remember to run make-all before committing... and to not merge things in which belong to the next inkscape version before it is released - and to not merge bzr ignore, of course.

The website could then get its updates from there.
Is this total nonsense or a possible option?

[jazzynico (jazzynico)]

> Making the docs depends even on non-free Java... (is this still true?) and inkscape and saxon...

Not tested with free Java implementations. Of course it would be great if we could get rid of Java and use another language (or script) with xsltproc or the libxslt library, but I'm almost they don't support XSLT 2.0...

> Then there could be another branch (for example "stable-web") in inkscape-docs with the finished docs.

Very good idea Maren! I already have a local directory for the generated files that need to be sent to the web site. It would be quite easy to commit them in a specific branch or a specific directory in the inkscape-docs main branch.
Then the process would be simplified, and we would just need someone (or something, if cron based) from the website side check the inkscape-docs branch and apply the changes regularly, as you mentioned.

Martin, if it's ok for you I can work on it later this week . Just tell me your preference regarding the files location (main branch or specific branch in the inkscape-docs project).

[Martin Owens (doctormo)]

I'm adding a list of the unclean docs directory currently on live. I will trust the inkscape-docs team to control the directory and all of it's contents and can place a bzr checkout in the right place using the existing scripts we already use to deploy the website's own code.

[jazzynico (jazzynico)]

@Martin, I'm currently working on it, but I feel we could improve how the list is organized. I know it will affect the website configuration, but how about moving the tutorials in a tutorials directory and all the development documentation in a dev directory? We could also create a new keys directory that would be used in the help menu link as of 0.91?
The only "hard" links I'm aware of are the keys files for 0.46 to 0.48 inkscape versions, and thus I guess that apart from it there's no problem changing the docs directory.

[Martin Owens (doctormo)]

The contents of the docs directory is completely up to you. If you need more than one root directory on the website, just let me know the setup and how the content will be delivered. (i.e. bzr)

[Hachmann (marenhachmann)]

Marking this as Fix Released now, as this discussion led to a permanent solution for updating documentation on the live website.