Bug 66737

*** Bug 57794 has been marked as a duplicate of this bug. ***

I'd also like user-defined shortcuts for a given sessions - even if those shortcuts hide the ones, that terminal application requires. This is a pretty useful option! Think about it, developers :^)

Created attachment 8475 [details]
Allows user to create shortcuts for Session entries.

Hard part was getting the shortcuts to work when makeGUI hadn't been called
yet.  I'll need to look at this again...

All the shortcuts are off by default.

Created attachment 8496 [details]
Allows user to create shortcuts for Session entries.

This seperates the loading of Sessions and the creation of the menus.  This
patch will load all the .desktop files upon startup; which will obviously slow
things down.  I don't see a way around this unless the shortcuts are read and
checked to see if any of them are for Sessions.

With 7 .desktops loaded, I get a time.elapsed of 7 msecs for the code in Comment #4.  This 'seems' to be decent.

Well, yes, but it will be a lot more if they are not 'hot' in the diskcache and the disk actually has to seek for each one of them.

It would be great to have it implemented.
Thanks Kurt :)

Comment #6:  Yes, I didn't think about that... how do you remove the files from the 'cache' to test the full time?

Well, anyway, there are only 2 ways to do this:
1. Read all the .desktops at startup (comment #4)
2. Read the shortcuts; search through them looking for 'session shortcuts' (simple enough, preprend 'SessionSC' to the shortcut names and search for that); if any are found; read all the .desktops; reread the shortcuts.  I have code for this as well.

Perhaps #2 is better?

Comment #9 point 2 doesn't work.  readShortcuts() ignores any shortcuts it doesn't know about.  So unless someone explains another way, the patch in #4 is the only way I know to do this...

Created attachment 8662 [details]
Allows user to create shortcuts for Session entries.

Yikes, this patch is getting big/complex.  Anyway, this should be it.  The
.desktop files are only loaded if the user has a shortcut to a session entry.
I would like to commit this before the 3.4 freeze... please look/test it.

> Yikes, this patch is getting big/complex.  Anyway, this should be it. 
> The .desktop files are only loaded if the user has a shortcut to a
> session entry. I would like to commit this before the 3.4 freeze...
> please look/test it.

That's it :) Many, many thanks.

But there are major problems with adding and removing of sessions:
- when adding section list of available shortcuts isn't updated. New
  sessions are visible only in new instance of Konsole. Acceptable, but
  :/

- complete mess when removing sessions. They are still visible in
  session shortcuts, in pop-up window with possible endings of
  shortcuts, and after completion results are unexpected: looks like
  unexpected shift in array. After restart everything works.

Asking for file with schema has any sense?
If user for example remove .deskop extension has it some bad
consequences, same question for main name?

At the end layman question: wouldn't be easier just assigning shortcuts
in session configuration dialog?

The adding/removing of sessions is something I've overlooked.

1. The overall problem is the loading of the .desktop files; previously it is done when the user opens the menu or clicks on any button that generates a menu.  This is too late for the session shortcuts.
2.  The sessions are defined in .desktop files... that's the way they always will be.
3. Even if the assigning of the shortcuts are in the session config, the .desktop files have to be loaded at konsole startup to be useable (see #1).

I'll look at this again later today...

> 1. The overall problem is the loading of the .desktop files; previously
> it is done when the user opens the menu or clicks on any button that
> generates a menu.  This is too late for the session shortcuts. 
Sorry, forgot about that.
> 2.  The sessions are defined in .desktop files... that's the way they
> always will be. 
I am not questioning this. Just don't see any sense with allowing user
to mess with this. Forget about that - this is thing for another bug/wish.

Created attachment 8688 [details]
Allows user to create shortcuts for Session entries.

The creating/deleting sessions problem should be fixed.
Please test this fully...

> The creating/deleting sessions problem should be fixed.
> Please test this fully...

Works really pretty now. But still one thing :)
- new session, Vim (calling vim)
- assign shortcut 'Ctrl-L,V'
- remove session with name Vim
- create session with the same name 'Vim' old shortcut is automatically
  reassigned; even after restart of Konsole.

Looks like patch doesn't remove shortcut assignments and they are
automatically recalled when session with that name is visible again.

Things go astray when:
- new session, Vim (calling vim)
- assign shortcut 'Ctrl-L,V'
- remove session with name Vim
- create new session 'top' (with top command)
- assign shortcut 'Ctrl-L,V'
- create new-old session 'Vim'

No crashes but after pressing 'Ctrl-L,V' Konsole doesn't know what to
do.

Thanks for testing it; I'll apply this patch Friday unless there is objection.  I'll fix the problem you noticed.

CVS commit by hindenburg: 

BUG: 66737
Allows user to assign shortcuts to Sessions entries (.desktop files).


  M +111 -17   konsole.cpp   1.490
  M +6 -0      konsole.h   1.188