Open GoogleCodeExporter opened 9 years ago
When the interface is localized (e.g., for French), the predefined shortcuts
could be changed - this is at the
discretion of the translator. However, the problem that AltGr keys are not
recognized on Windows definitely
needs to be resolved.
The request for user-customized shortcuts (and macros) is a bigger issue,
probably not for a first release but
definitely desirable in the future.
Original comment by jfkth...@gmail.com
on 9 Aug 2008 at 4:56
When you localize, it is as "firmware" (??!!), not accessible to the user.
Would it be possible to have localisation in .xml files.
For example with TeXnicCenter, there are three files in the "packages" folder
(base.xml, math.xml and tex.xml) in which TeX modules are defined (and could be
modified for errors!!).
If TeXworks would use such files it could be easy to add macros, shortcuts,...
But I do not know if offering this possibility is easy :-(
Original comment by lal.stu...@yahoo.fr
on 26 Aug 2008 at 12:57
I attached a patch that enables the user to use custom shortcuts for all named
actions in TeXworks. I also attached a file listing all supported named actions
for r252.
To use it, follow this procedure:
1) Create an ini file for mapping your custom shortcuts. Example:
actionOpen = Alt+O
actionPaste = Ctrl+V
Don't use any spaces in the shortcut definition. Backslash characters have to be
escaped (use "\\" instead of "\"). See
http://doc.trolltech.com/4.4/qsettings.html#Format-enum for more information.
2) Add the line
shortcutsMapFile=<path-to-your-ini-file>
to your TeXworks configuration
(http://doc.trolltech.com/4.4/qsettings.html#platform-specific-notes may give
you a
hint where to look)
Limitations/Caveats:
* Currently I haven't implemented a preferences dialog field.
* Currently only works for TeXDocument and PDFDocument windows (i.e. not for
the Mac
top-level menu). Should be fairly easy to adopt, though (use
QAction::setObjectName()
to support them).
* Doesn't currently work for dynamically added menu items (i.e. recent
documents) for
the same reason.
Original comment by st.loeffler
on 6 Jan 2009 at 2:30
Attachments:
Thanks for looking into this, Stefan. Seems like this would be a good starting
point, and could be extended
further in due course. E.g., we could present the shortcuts in a Preferences
panel using a QTableWidget, and
update them dynamically in a similar way to on-the-fly language changes. But
even just supporting a text file,
as you've done here, is a great start.
Glancing through the patch, I wondered about the purpose of running the
shortcuts through the QObject::tr()
function in TWUtils::installCustomShortcuts(). Surely the shortcut file will
already contain the right thing (i.e., the
actual shortcut that the user wants). Or am I missing something?
Original comment by jfkth...@gmail.com
on 12 Jan 2009 at 8:29
A table to customize the shortcuts on-the-fly would be a logical enhancement. I
haven't looked into this so far, however, as this may be tricky to do in a
system-independent, user-friendly way (i.e. the user just clicks on the
shortcut to
change and presses the new key(-combination)). This would involve interception
of key
messages and/or an app-modal dialog to receive those keys. In any case there
should
be the option to import/export a shortcut table to/from text files to make it
easy
for people to publish "standard" shortcut lists for non-English keyboards.
Since that
seemed to be a major issue for many users both here and on the mailing list I
thought
I'd start with that ;).
The QObect::tr() thingy was copied from the Qt Doc under the assumption that
otherwise the displayed shortcut strings wouldn't be translated to the current
language (Ctrl is Strg in German, for example). After a few tests and some
further
reading I figured out now that the tr() is in the documentation only to enable
changing a (static) shortcut so we won't need that here.
One more caveat I forgot last time:
* Currently it's not possible to assign context-aware shortcuts. If two
(possibly
different) actions (i.e. in the tex and the pdf windows) have the same
ObjectName
they get the same shortcut. This could easily be remedied by introducing
window-specific sections into the mapping file. This would possibly lead to
redundancy in the file, however (i.e. the same shortcut would most likely be
used for
"Open" in all windows). The better way would probably be to give such
(conflicting)
actions different names.
Original comment by st.loeffler
on 13 Jan 2009 at 8:02
I didn't test yet the ini system of Stefan to add shorcuts.
I had first to understand that the actionSomething are coming from the source
files
(but what is a .ui, .h or .cpp file?)
Anyway I'll do a list of the actionS adding the shortcuts defined in the .ts/.qm
files (unless it is already done.)
There are some actions I'dd like to have for editing the TeX source: actionEmph,
actionTextBF, actionTextIT, actionTextSL, actionTextTT and actionTextSC. These
would
embed a selected text in the corresponding command: \emph{selected_text}. The
selection should remain, so it would be possible to apply 2 or more commands to
the
same selection.
NB. The same behaviour, maintain the selection, could perhaps be used for the
paste
command??!!
These actions could appear (or not) in the Format menu or one of its submenu.
A more general action would also be actionApplyCompletion on a selection: when
used a
popup menu, with ? (I don't remember the name: a list appears which is adjusted
by
subsequent inputs) to select a completion shortcut, apply it and have the
original
selection at the place of #INS#.
Example: I want to put some text in a verbatim environment: I select it, ask
actionApplyCompletion, type b...v... to finaly select bverb, then ?[Enter] to
have
the text between \begin{verbatim} \end{verbatim}
Original comment by lal.stu...@yahoo.fr
on 14 Jan 2009 at 8:34
.h are header files, .cpp are c++ files. They contain the source code. The .ui
files
are user interface files that are created i.e. using QtDesigner. They basically
define the way windows look and what menus and menu items exist.
I've attached a list of currently available actions (actions.txt) to my original
comment. They don't contain the standard shortcuts, they are only meant as a
reference. If you need a list on actions with the default shortcuts that's quite
simple to generate automatically (i.e. you don't have to do it by hand).
Adding new actions isn't that simple, though. It would require a lot of changes
to
the internals of TeXworks. However, the formatting commands you mention have
been
implemented in terms of a different code completion mechanism already. If you
type
"sf" followed by the tab key it expands to \textsf{} with the cursor positioned
between the braces. Hit tab multiple times to access other meanings of sf (if
available). For a complete list of code completion templates refer to the files
in
the res/resfiles/completion subdirectory of the TeXworks sources or the
completion
folder inside your TeXworks configuration directory (under Linux, it's
~/.TeXworks,
under Windows it's probably C:\Documents and Settings\<username>\TeXworks).
Hope this helps
Stefan
Original comment by st.loeffler
on 14 Jan 2009 at 9:43
I didn't take care to the action.txt file.
About the second comment: I am already a lot using the completion, including for
formating.
But I often have files which I have to format *afterwards*, that is, the text
already
exists and I have to apply emph, bold,...
So now I have to: locate in front of the text, type em+[space], [left arrow],
[Tab],
the completion is done "\emph{}", delete "}", delete "space", move to the end
of the
text to emphasize, type }
This is quite a painfull system (I did it for a 70 pages long text with many
emph};
so selecting and applying em would be a real help.
This was the very first reason to ask for the hability to create shortcuts.
Alain
Original comment by lal.stu...@yahoo.fr
on 14 Jan 2009 at 1:20
I understand your wish to have a more convenient way to apply such commands.
However, this requires a
slightly different approach, as you don't just need to be able to assign your
chosen shortcut to an existing
operation in the program; you need to be able to define a custom editing
operation, too.
I don't want to hard-code a collection of LaTeX markup options such as
\emph{...}, etc., as "actions" that can
have Qt shortcuts assigned; rather, I'd like to have an editable file of "text
fragments" similar to the
completions, but available to insert from a menu, palette, or something like
that. Such fragments could be
inserted as-is at the current cursor position, or if there is a selection, they
would define how to interact with
it (replace the selection, or insert before, after, or around it).
Original comment by jfkth...@gmail.com
on 14 Jan 2009 at 2:45
That is exactly what I would like to have!
I did propose the harcoded solutions as "easier" solutions!!
Now I have many things to test, so I'll be quite for some time!!
Original comment by lal.stu...@yahoo.fr
on 14 Jan 2009 at 4:12
Unfortunately, the original patch didn't work on Windows (thanks to Alain for
keeping
reminding me of it ;)). This should be fixed with the attached patch (which is
supposed to replace the original one).
For those who are interested: The error was that pre-portable configuration
code was
used. This means that the configuration was not taken from the custom ini
files, but
from the registry. Hence no custom shortcut file was loaded. This also explains
why
this problem only occurred on Windows.
Original comment by st.loeffler
on 11 Jun 2009 at 3:29
Attachments:
Committed a variant of this patch. It will load shortcuts from a file named
"shortcuts.ini" in the TeXworks
configuration folder, if it exists, rather than requiring a special entry in
the main settings file.
Original comment by jfkth...@gmail.com
on 28 Jun 2009 at 9:35
Hi,
I just wanted to say thanks for this:
> Committed a variant of this patch. It will
> load shortcuts from a file named "shortcuts.ini"
I just discovered Texworks for Linux, and I think it is great - unfortunately,
sometimes if I make error in my Tex file, compile it with error, and then
correct the
error, compilation still fails (something about missing \par) and it will not
build
correctly unless Aux files are removed - and the Remove aux files option
doesn't have
a shortcut by default. (Btw, choose Ctrl-Alt-R for this, since both Ctrl-R and
Ctrl-Shift-R are taken)... Now if it could just remember the choice not to
delete say
the .blg file :)
Btw, I run Texworks "portably" (from a folder) and all I needed to do was to
create a
new shortcuts.ini file in ~/.TeXworks/configuration (for Ubuntu); an example
file can
be found on http://www.leliseron.org/texworks/shortcuts.ini ...
Thanks again,
Cheers!
Original comment by s...@imi.aau.dk
on 9 Mar 2010 at 7:54
Could I request that to the configurable keyboard-short cut actions be added
the actual drop-down menus on the main editing and preview screens?
I'm habituated to typing Alt+f and getting the File menu drop down, with my
cursor on it, whence I can select whatever I want by moving and pressing enter.
I looked for a way to set this up with the current TeXworks, and couldn't find
it. Perhaps I'm missing something, but I would expect this to be implemented
as something like actionMenuFile, actionMenuEdit, actionMenuSearch, etc.
GNU/Linux, Ubuntu 10.04, TeXworks 0.3 r.671 (launchpad)
Thanks
Dominik
Original comment by wujas...@gmail.com
on 12 Aug 2010 at 3:31
There are some differences in the underlying code, so accelerator keys
(underlined letters in the menu) are not dealt with by the action... code.
Instead, this has to be done in the translation/localization file.
Alain Delmotte has posted such a customized file for English on the mailing
list (http://tug.org/pipermail/texworks/2010q2/002606.html). If you use a
different language, you'd probably need to add them yourself. For this, see the
"Translating" page on the wiki (you'd need to add a "&" character in front of
the character you want underlined).
Original comment by st.loeffler
on 13 Aug 2010 at 8:33
Many thanks. After downloading attachment.obj from Tug.org, and renaming it
TeXworks_en.qm, and placing it in ~/.TeXworks/translations , it worked!
This really helps a lot, making TeXworks much more friendly and easy to use.
Many thanks!
Dominik
Original comment by wujas...@gmail.com
on 18 Aug 2010 at 3:48
Could "personal macro's" header area's ...
// Description: Text here Text here Text here
Description be made to show as a mouse over hint, on the Script's position on
the Scripts Menu please?
Paul
Original comment by paul.a.norman
on 6 Nov 2010 at 6:21
Hey,
i recently switched from TeXshop to TeXworks and missed the shortcuts for the
different typesetting engines (so you don't have to click the
dropdownmenu/menubar).
So I grabbed the SVN and patched it myself. I did't succeed, because I my Qt
SDK is kind of messed up right now (major include path issues, stupid
macosx...).
After that I noticed this thread. If it helps, i attached my patch... it's
untested for now (see above).
Either way, shortcuts for the engines would be nice (customizable or not, i
personally don't care).
Richard
Original comment by dasri...@gmail.com
on 9 May 2011 at 1:06
Attachments:
Is there any way for me to use the j and k keys to move up and down by SCREEN
line?
I'm am trying to create a system of scripts that let me navigate by pressing
the Ctrl key, plus keys in or near the home row. (Sorta vim-like, I guess.) So
far I can move by characters, words, and code-lines (or anything else I can
search TW.target.text for). But not screen lines.
I can think of two possibilities:
1. Is there some way I could map the up and down arrow keys to Ctrl+j and
Ctrl+k?
2. Is there some TW api property that tells me the position of the next screen
line up and down? If so I could write a script that then uses
TW.target.selectRange(x) to move the cursor there.
I'd be grateful for any ideas, thanks!
Jonathan
I am trying to make a script to move the cursor up and down by screen lines.
(My documents are not hard wrapped so I
Original comment by jonathan...@yahoo.ca
on 29 Jul 2012 at 8:41
Initially I found TeXWorks to be hardly usable on windows, because commenting and indenting by keyboard is one of the main features I use almost on a per-line basis, and the default shortcuts were not usable. I'm using the .ini-approach for now, which mitigates the issue. Still ... this seems to be a widely used editor, so I personally find it strange that this has stayed open for a bit more than nine years now.
Original issue reported on code.google.com by
lal.stu...@yahoo.fr
on 9 Aug 2008 at 3:02