Hello Thorsten,
I certainly appreciate engaging in this dialog. I think we can all find some
common ground here.
> > * Shortcuts should accept multiple shortcuts "Ctrl+O,
> Enter".
>
> Hmm, Ctrl+O is for opening a file and Enter is for opening
> a segment in an
> editor. Maybe the term shortcut is not appropriate in this
> context. This
> code is only able to change the key that is connected to an
> entry in the
> menue. As far as I know, only Ctrl+V, Ctrl+X and Ctrl-C
> have several
> "shortcuts" in the rc-files but only one is visible in the
> menue.
Looking at the code, I see that this is a qt3 vs. qt4 thing. We've seen
similar partial functionality with other Qt3 support code.
We are using setAccel (from qt3) this will need to change to
setShortcut(QKeySequence).
This will probably fix the multiple shortcuts per QAction issue.
Each QAction is allowed up to four shortcut keys assigned.
I mentioned "Ctrl+O, Enter" as an example. My testing was for used unused
shortcuts so there was not conflict.
> > * Shortcuts, upon hitting the Ok button, rewrote every
> shortcut for the
> > screen. Maybe I'm being picky here,
> but I'd like to see this done a
> > little more elegantly
>
> Yes, any changes are made instantly. What do you mean by
> more elegantly?
Currently, when OK is pressed we do this:
for (int row = 0; row < (int)m_shortcutsList.size(); ++row) {
QAction *shortcut = m_shortcutsList[row];
RG_DEBUG << "ShortcutsDialog: accept " << row << " = " <<
m_shortcutsTable->text(row, 1) << endl;
shortcut->setAccel(QKeySequence(m_shortcutsTable->text(row, 1)));
}
This sets every shortcut listed in the dialog box. So if there are 30
shortcuts listed, pressing ok, even if a few (or zero) are changed, every
shortcut gets updated.
I would suggest that we track the updates. If it validates we can just have a
Map<Int, Row> (or something) to store the updates
Then we could just iterate over the keys and set the shortcuts when OK is
pressed.
That is what I meant by more elegant (efficient may have been a better word
choice).
> > * Use of tr() missing which will help with some of the
> translation issues.
> > For an example see:
> > http://doc.trolltech.com/4.5/qkeysequence.html#QKeySequence-2
>
> Hmm, that is something I don't understand. Any parameter
> that is passed to
> QKeySequence is already translated (as it comes from
> querylist("QAction")
> which contains the translated strings from the menue).
I'll have to look into this a bit myself...this issue is not firm in my mind
either.
> > * All shoprtcuts are saved under a "shortcuts"
> group. This will need
> > to be expanded separate each screens shortcuts.
>
> On the other side there is only one Ctrl-X shortcut within
> the whole
> program. So why do you want to split this for different
> screens? Isn't it
> better to change every shortcut only once and then have it
> available
> everywhere?
>
Yes, you are correct, that things like Ctrl+X should be application wide. From
my understanding when I look at the .rc files, I see that File, Cut, Paste,
Copy, and many other shortcuts are explicitly added in each file and short cuts
are listed.
>From my understanding Of .rc files, FileActionClient.cpp, and
>FileActionParser.cpp
Only .rc entries with "shortcut-context="application"" will have application
wide context.
RG's current implementation does not set up many of the "standard" shortcuts as
application wide.
It only has the appearance of being global because we crafted it that way. I
know this personally since I coded many of the .rc files myself and tried very
hard to get all the shortcuts (from several conflicting platforms) to match-up.
Maybe Chris C has better knowledge about all of this -- some things Qt related
are still a mystery to me.
So it isn't that I want them separate. They are separate. Every screen will
need the same tweak for many of these standard shortcuts.
I hope this is making sense.
> > * Shortcut editor should be integrated to the
> Edit->Preferences. That is
> > where the action takes place for things like this in
> RG.
>
> Wouldn't someone who is using shortcuts prefer to change
> these shortcuts
> only by pressing some keys?
I don't understand what you mean by "only by pressing some keys?"
Integration of the shortcut editor into Edit -> Preferences... is not a
must...just an initial vision.
> > * The Shortcut Editor should be Application wide, not
> one dialog for each
> > window. People need a central location to edit
> these shortcuts.
>
> If you see a window, you might only want to change the
> shortcuts of that
> window. It might be more clearly to not search the whole
> list for the
> entry you want to change.
Point taken. Assuming we can work out the several issues concerning
Application wide vs. window context a per window approach may a much lighter
weight design and allow the user an easy indicator as to which window the
shortcuts they edit are affecting.
> > * Provide a way to export / import the shortcuts.
Another idea, but not needed. I can see uses for it across several
installs...but mostly is is a heavy weight feature that provides little benefit
for most users...pretend I did not mentioned it.
Sincerely,
Julie S.
------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
