kicad/include/hotkeys_basic.h

183 lines
7.0 KiB
C
Raw Normal View History

/*
* This program source code file is part of KiCad, a free EDA CAD application.
*
2019-06-09 21:57:23 +00:00
* Copyright (C) 2004-2019 KiCad Developers, see AUTHORS.txt for contributors.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, you may find one here:
* http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
* or you may search the http://www.gnu.org website for the version 2 license,
* or you may write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
*/
2007-08-20 11:33:45 +00:00
#ifndef HOTKEYS_BASIC_H
#define HOTKEYS_BASIC_H
2019-06-09 21:57:23 +00:00
#include <map>
#include <common.h>
#define DEFAULT_HOTKEY_FILENAME_EXT wxT( "hotkeys" )
#define EESCHEMA_HOTKEY_NAME wxT( "Eeschema" )
#define PCBNEW_HOTKEY_NAME wxT( "PcbNew" )
// A define to allow translation of Hot Key message Info in hotkey help menu
// We do not want to use the _( x ) usual macro from wxWidgets, which calls wxGetTranslation(),
// because the English string is used in key file configuration
// The translated string is used only when displaying the help window.
// Therefore translation tools have to use the "_" and the "_HKI" prefix to extract
// strings to translate
#include <i18n_utility.h> // _HKI definition
2019-06-09 21:57:23 +00:00
class TOOL_ACTION;
class TOOL_MANAGER;
class EDA_BASE_FRAME;
/* Identifiers (tags) in key code configuration file (or section names)
* .m_SectionTag member of a EDA_HOTKEY_CONFIG
*/
extern wxString g_CommonSectionTag;
/**
* class EDA_HOTKEY
* is a class to handle hot key commands. Hot keys have a default value.
* This class allows the real key code changed by user(from a key code list file)
*/
class EDA_HOTKEY
2007-08-20 11:33:45 +00:00
{
public:
int m_KeyCode; // Key code (ascii value for ascii keys or wxWidgets code for function key
wxString m_InfoMsg; // info message.
int m_Idcommand; // internal id for the corresponding command (see hotkey_id_command list)
int m_IdMenuEvent; // id to call the corresponding event (if any) (see id.h)
2007-08-20 11:33:45 +00:00
public:
EDA_HOTKEY( const wxChar* infomsg, int idcommand, int keycode, int idmenuevent = 0 );
2007-08-20 11:33:45 +00:00
};
/**
* Structure EDA_HOTKEY_CONFIG
* contains the information required to save hot key information to a configuration file.
* a Section name and the corresponding list of hotkeys (EDA_HOTKEY list)
2007-09-19 15:29:50 +00:00
* hotkeys are grouped by section.
* a section is a list of hotkey infos ( a EDA_HOTKEY list).
* A full list of hotkeys can used one or many sections
2007-09-19 15:29:50 +00:00
* for instance:
* the schematic editor uses a common section (zoom hotkeys list ..) and a specific section
* the library editor uses the same common section and a specific section
* this feature avoid duplications and made hotkey file config easier to understand and edit
2007-09-19 15:29:50 +00:00
*/
struct EDA_HOTKEY_CONFIG
{
public:
2019-06-09 21:57:23 +00:00
wxString* m_SectionTag; // The configuration file section name.
EDA_HOTKEY** m_HK_InfoList; // List of EDA_HOTKEY pointers
wxString* m_Title; // Title displayed in hotkey editor and used as comment in file
};
2007-09-19 15:29:50 +00:00
/**
* KIWAY Milestone A): Make major modules into DLL/DSOs. ! The initial testing of this commit should be done using a Debug build so that all the wxASSERT()s are enabled. Also, be sure and keep enabled the USE_KIWAY_DLLs option. The tree won't likely build without it. Turning it off is senseless anyways. If you want stable code, go back to a prior version, the one tagged with "stable". * Relocate all functionality out of the wxApp derivative into more finely targeted purposes: a) DLL/DSO specific b) PROJECT specific c) EXE or process specific d) configuration file specific data e) configuration file manipulations functions. All of this functionality was blended into an extremely large wxApp derivative and that was incompatible with the desire to support multiple concurrently loaded DLL/DSO's ("KIFACE")s and multiple concurrently open projects. An amazing amount of organization come from simply sorting each bit of functionality into the proper box. * Switch to wxConfigBase from wxConfig everywhere except instantiation. * Add classes KIWAY, KIFACE, KIFACE_I, SEARCH_STACK, PGM_BASE, PGM_KICAD, PGM_SINGLE_TOP, * Remove "Return" prefix on many function names. * Remove obvious comments from CMakeLists.txt files, and from else() and endif()s. * Fix building boost for use in a DSO on linux. * Remove some of the assumptions in the CMakeLists.txt files that windows had to be the host platform when building windows binaries. * Reduce the number of wxStrings being constructed at program load time via static construction. * Pass wxConfigBase* to all SaveSettings() and LoadSettings() functions so that these functions are useful even when the wxConfigBase comes from another source, as is the case in the KICAD_MANAGER_FRAME. * Move the setting of the KIPRJMOD environment variable into class PROJECT, so that it can be moved into a project variable soon, and out of FP_LIB_TABLE. * Add the KIWAY_PLAYER which is associated with a particular PROJECT, and all its child wxFrames and wxDialogs now have a Kiway() member function which returns a KIWAY& that that window tree branch is in support of. This is like wxWindows DNA in that child windows get this member with proper value at time of construction. * Anticipate some of the needs for milestones B) and C) and make code adjustments now in an effort to reduce work in those milestones. * No testing has been done for python scripting, since milestone C) has that being largely reworked and re-thought-out.
2014-03-20 00:42:08 +00:00
* Function KeyNameFromKeyCode
* return the key name from the key code
* * Only some wxWidgets key values are handled for function key ( see
* s_Hotkey_Name_List[] )
* @param aKeycode = key code (ascii value, or wxWidgets value for function keys)
* @param aIsFound = a pointer to a bool to return true if found, or false. an be NULL default)
* @return the key name in a wxString
*/
2019-06-09 21:57:23 +00:00
wxString KeyNameFromKeyCode( int aKeycode, bool * aIsFound = nullptr );
/**
* KIWAY Milestone A): Make major modules into DLL/DSOs. ! The initial testing of this commit should be done using a Debug build so that all the wxASSERT()s are enabled. Also, be sure and keep enabled the USE_KIWAY_DLLs option. The tree won't likely build without it. Turning it off is senseless anyways. If you want stable code, go back to a prior version, the one tagged with "stable". * Relocate all functionality out of the wxApp derivative into more finely targeted purposes: a) DLL/DSO specific b) PROJECT specific c) EXE or process specific d) configuration file specific data e) configuration file manipulations functions. All of this functionality was blended into an extremely large wxApp derivative and that was incompatible with the desire to support multiple concurrently loaded DLL/DSO's ("KIFACE")s and multiple concurrently open projects. An amazing amount of organization come from simply sorting each bit of functionality into the proper box. * Switch to wxConfigBase from wxConfig everywhere except instantiation. * Add classes KIWAY, KIFACE, KIFACE_I, SEARCH_STACK, PGM_BASE, PGM_KICAD, PGM_SINGLE_TOP, * Remove "Return" prefix on many function names. * Remove obvious comments from CMakeLists.txt files, and from else() and endif()s. * Fix building boost for use in a DSO on linux. * Remove some of the assumptions in the CMakeLists.txt files that windows had to be the host platform when building windows binaries. * Reduce the number of wxStrings being constructed at program load time via static construction. * Pass wxConfigBase* to all SaveSettings() and LoadSettings() functions so that these functions are useful even when the wxConfigBase comes from another source, as is the case in the KICAD_MANAGER_FRAME. * Move the setting of the KIPRJMOD environment variable into class PROJECT, so that it can be moved into a project variable soon, and out of FP_LIB_TABLE. * Add the KIWAY_PLAYER which is associated with a particular PROJECT, and all its child wxFrames and wxDialogs now have a Kiway() member function which returns a KIWAY& that that window tree branch is in support of. This is like wxWindows DNA in that child windows get this member with proper value at time of construction. * Anticipate some of the needs for milestones B) and C) and make code adjustments now in an effort to reduce work in those milestones. * No testing has been done for python scripting, since milestone C) has that being largely reworked and re-thought-out.
2014-03-20 00:42:08 +00:00
* Function KeyNameFromCommandId
* return the key name from the Command id value ( m_Idcommand member value)
* @param aList = pointer to a EDA_HOTKEY list of commands
* @param aCommandId = Command Id value
* @return the key name in a wxString
*/
* KIWAY Milestone A): Make major modules into DLL/DSOs. ! The initial testing of this commit should be done using a Debug build so that all the wxASSERT()s are enabled. Also, be sure and keep enabled the USE_KIWAY_DLLs option. The tree won't likely build without it. Turning it off is senseless anyways. If you want stable code, go back to a prior version, the one tagged with "stable". * Relocate all functionality out of the wxApp derivative into more finely targeted purposes: a) DLL/DSO specific b) PROJECT specific c) EXE or process specific d) configuration file specific data e) configuration file manipulations functions. All of this functionality was blended into an extremely large wxApp derivative and that was incompatible with the desire to support multiple concurrently loaded DLL/DSO's ("KIFACE")s and multiple concurrently open projects. An amazing amount of organization come from simply sorting each bit of functionality into the proper box. * Switch to wxConfigBase from wxConfig everywhere except instantiation. * Add classes KIWAY, KIFACE, KIFACE_I, SEARCH_STACK, PGM_BASE, PGM_KICAD, PGM_SINGLE_TOP, * Remove "Return" prefix on many function names. * Remove obvious comments from CMakeLists.txt files, and from else() and endif()s. * Fix building boost for use in a DSO on linux. * Remove some of the assumptions in the CMakeLists.txt files that windows had to be the host platform when building windows binaries. * Reduce the number of wxStrings being constructed at program load time via static construction. * Pass wxConfigBase* to all SaveSettings() and LoadSettings() functions so that these functions are useful even when the wxConfigBase comes from another source, as is the case in the KICAD_MANAGER_FRAME. * Move the setting of the KIPRJMOD environment variable into class PROJECT, so that it can be moved into a project variable soon, and out of FP_LIB_TABLE. * Add the KIWAY_PLAYER which is associated with a particular PROJECT, and all its child wxFrames and wxDialogs now have a Kiway() member function which returns a KIWAY& that that window tree branch is in support of. This is like wxWindows DNA in that child windows get this member with proper value at time of construction. * Anticipate some of the needs for milestones B) and C) and make code adjustments now in an effort to reduce work in those milestones. * No testing has been done for python scripting, since milestone C) has that being largely reworked and re-thought-out.
2014-03-20 00:42:08 +00:00
wxString KeyNameFromCommandId( EDA_HOTKEY** aList, int aCommandId );
/**
* An helper enum for AddHotkeyName function
* In menus we can add a hot key, or an accelerator , or sometimes just a comment
* Hot keys can perform actions using the current mouse cursor position
* Accelerators perform the same action as the associated menu
* A comment is used in tool tips for some tools (zoom ..)
* to show the hot key that performs this action
*/
enum HOTKEY_ACTION_TYPE
{
IS_HOTKEY,
IS_COMMENT
};
/**
2019-06-09 21:57:23 +00:00
* AddHotkeyName
* @param aText - the base text on which to append the hotkey
* @param aHotKey - the hotkey keycode
* @param aStyle - IS_HOTKEY to add <tab><keyname> (shortcuts in menus, same as hotkeys)
* IS_COMMENT to add <spaces><(keyname)> mainly in tool tips
*/
2019-06-09 21:57:23 +00:00
wxString AddHotkeyName( const wxString& aText, int aHotKey,
HOTKEY_ACTION_TYPE aStyle = IS_HOTKEY);
/**
* Function AddHotkeyName
* Add the key name from the Command id value ( m_Idcommand member value)
* @param aText = a wxString. returns aText + key name
* @param aDescrList = pointer to a EDA_HOTKEY_CONFIG DescrList of commands
* @param aCommandId = Command Id value
* @param aShortCutType The #HOTKEY_ACTION_TYPE of the shortcut.
* @return a wxString (aTest + key name) if key found or aText without modification
*/
wxString AddHotkeyName( const wxString& aText,
struct EDA_HOTKEY_CONFIG* aDescrList,
int aCommandId,
HOTKEY_ACTION_TYPE aShortCutType = IS_HOTKEY );
/**
* Function DisplayHotkeyList
* Displays the current hotkey list
* @param aFrame = current active frame
2019-06-09 21:57:23 +00:00
* @param aToolMgr = the tool manager holding the registered actions from which the hotkeys
* will be harvested
*/
2019-06-09 21:57:23 +00:00
void DisplayHotkeyList( EDA_BASE_FRAME* aFrame, TOOL_MANAGER* aToolMgr );
/**
2019-06-09 21:57:23 +00:00
* Function WriteHotKeyConfig
* Updates the hotkeys config file with the hotkeys from the given actions map.
*/
2019-06-09 21:57:23 +00:00
int WriteHotKeyConfig( std::map<std::string, TOOL_ACTION*> aActionMap );
2007-08-20 11:33:45 +00:00
/**
2019-06-09 21:57:23 +00:00
* Function ReadLegacyHotkeyConfigFile
* Read hotkey configuration for a given app,
* possibly before the frame for that app has been created
* @param aFilename = the filename to save the hotkeys as
2019-06-09 21:57:23 +00:00
* @param aMap The list of keycodes mapped by legacy property names
* @return 1 on success, 0 on failure
*/
2019-06-09 21:57:23 +00:00
int ReadLegacyHotkeyConfigFile( const wxString& aFilename, std::map<std::string, int>& aMap );
/**
2019-06-09 21:57:23 +00:00
* Function ReadLegacyHotkeyConfig
* Read configuration data and fill the current hotkey list with hotkeys
* @param aAppname = the value of the app's m_FrameName
2019-06-09 21:57:23 +00:00
* @param aMap The list of keycodes mapped by legacy property names
*/
2019-06-09 21:57:23 +00:00
int ReadLegacyHotkeyConfig( const wxString& aAppname, std::map<std::string, int>& aMap );
2007-08-20 11:33:45 +00:00
#endif // HOTKEYS_BASIC_H