Kdevelop allows for split views (splitting the editor window horizontally or vertically) like known from Emacs and other editors. There are even shortcuts to create such splits (Ctrl+Shift+T, Ctrl+Shift+L), but I couldn't find any shortcut to switch between the splits. Is there any way of defining shortcuts for switching between splits?
Curiously, Kate offers the same split functionality but offers "next split view" and "previous split view" in Settings->Configure Shortscuts...
Just found a corresponding open feature request on bugs.kde.org indicating that this is not yet implemented.
However, [Ctrl]+[Tab], which is used to switch between opened files also switches between split views if the chosen file is opened in another view.
Related
Is there a way to make project explorer in eclipse look like source insight
As you can see in the right panel there is a listing of all files which can be sorted by name and is searchable which is way better than eclipse
You may get better answers by providing a screenshot as an example of what you want to achieve. But I'll do my best.
As far as I know, the Project Explorer (by default) sorts files by name, with folders preceding files. But this only applies to tree leaves (files within each directory). I don't think it is possible to use it to display all files, despite directory, in alphabetical order.
A sort of ugly (in my opinion) workaround could be to use the Ctrl+Shift+R keyboard shortcut and search for '**'. This will list all file names in all open projects within the current workspace. The default sort is by name.
You can see where any of these files is in the file tree by selecting the result and clicking the 'Show in' drop-down menu at the bottom of the dialogue box, and selecting 'Navigator'.
You can open any of these files by selecting the result and clicking the 'Open with' drop-down menu instead, and selecting the appropriate application to open it with.
Consider some alternative options:
If you're looking for a way to search for files by name, you can always use the keyboard shortcut Ctrl+Shift+R and type in the beginning of a file name. This is a hard search, but you can somewhat mimic a fuzzy search by using '?' to represent any character and '*' to represent any string (including the empty string). This scope of this search will include the names of all files in all open projects in the current workspace.
If you're looking to organise files for a manual search, the Navigator View allows sorting to be toggled between 'by Name' or 'by Type', but like the default for Project Explorer and Package Explorer, sorting applies only to tree leaves (within each directory). This can be set via 'View Menu' -> 'Sort' -> 'by Name' or 'by Type'. ('View Menu' is a button in the top right corner displayed as a white, hollow, downward facing arrow head.)
Kdevelop allows for split views (splitting the editor window horizontally or vertically) like known from Emacs and other editors. There are even shortcuts to create such splits (Ctrl+Shift+T, Ctrl+Shift+L), but I couldn't find any shortcut to close view. How to close the view in Kdevelop? I feel that this is rather stupid question, but I checked menus, shortcut list, context menu and see nothing about that...
The KDevelop editor is based on Kate, so you'd think that using the equivalent Kate command to close a view (Crtl+Shift+R) would work, but it doesn't seem to be implemented. Many of the Kate shortcuts are available to be assigned in the Configure Shortcuts dialog, but again, not close window.
The only canonical way to close the view is to close all the open files in it.
It's sub-optimal, but if you are desperate for a keyboard shortcut, Crtl+Shift+W will close all but your current document, which has the side effect of also removing any other views.
This might be a good candidate for a feature request.
It appears that there is no keyboard shortcut for this feature.
But, as of KDevelop 5, you can grab an edge of the split and drag it all the way up for a horizontal split and to all the left or right for a vertical split. This will close the other split view.
Any files opened in the other split view will be closed.
I sometimes have a large amount of query windows open in SSMS 2008.
Is there a keyboard shortcut to navigate between open query windows? Go to previous/next open query window?
I know there is Ctrl+Tab that allows you to select a query window, but it's only helpful if you have named windows.
A challenge you'll find here is what does "next" really mean? Since you can tear off tabs, split the UI, even move tabs onto different monitors, I think "next" and "previous" lose a little meaning, unless you know what order they were opened in.
Anyway, some solutions, with older versions (based on when the question was asked) left intact:
SSMS 2008
Ctrl+F6 will switch between two most recent tabs. And honestly, Ctrl+Tab / Ctrl+Shift+Tab work like next/previous except you have to hit Tab twice (you can ignore knowing what the name of the tab in the list is).
SSMS 2012
Ctrl+F6 will cycle through open tabs in the order they are displayed, and Ctrl+Shift+F6 will cycle in the reverse direction.
Ctrl+Tab / Ctrl+Shift+Tab will open a temporary window and allow you to cycle through open queries in the order they were last opened.
In more recent decades
Ctrl+Alt+[Page Up|Page Down] will cycle through windows (as bridge_burner added), but there's a catch. This only works when the query window is active - and it will stop working if you get to a query window where, previously, you had an item in the grid selected, for example.
You can make your own keyboard shortcut, as Stuart Smith explains.
the equivalent of Ctrl+Tab in browsers for SSMS would be Ctrl+Alt+PageDown for next tab and Ctrl+Alt+PageUp for previous tab.
Here's my approach that get's me closer to coding utopia. Make sure you keep your SSMS query windows sorted by name from left to right. SQLQuery1.sql, SQLQuery2.sql, etc. These are the default names SSMS gives these tabs when you create them (by clicking New Query).
To change the current query window tab, press "alt" then "w" then "w". A window is shown listing all of your open query windows sorted by their names (which should be the same order in which you have them laid-out from left to right). Use the up and down arrow keys to highlight the tab you want to activate and press enter. Your desired tab should be open now.
This allows me to quickly change query windows while keeping my fingers on the keyboard (less mouse usage).
I know this is a very old thread, but I thought I would add one more suggestion in case someone else comes across this: Redgate's SQL Prompt comes with a nifty "Tab History" applet that gets added as a button to a toolbar. I know that that means you would have to leave the keyboard and reach for the mouse to access it, but the interface and its functionalities are worth it! Not only do you have access to the currently opened tabs (with visual mini previews of the code in each tab) but also you have access to recently closed tabs (Yes, it may save you in case you accidentally close a tab without saving your work...)
Just my two cents. Best, Raphael
I found a way to map the browser style next/previous tab shortcuts in SSMS.
Select Tools > Options. Under 'Environment' select 'Keyboard'. In the 'Show commands containing:' area type 'Window.'.
Find 'Window.NextTab'. Toggle the 'Use new shortcut in:' to 'SQL Query Editor' then enter Ctrl + PgDn in the 'Press shortcut keys:' area and select 'Assign'. Do the same steps for 'Window.PreviousTab' with Ctrl + PgUp.
SSMS Keyboard Shortcuts Screenshot
I add my menu items shortcut keys, but they are poorly arranged.
and I need to make it like this:
Ah, I think I finally figured out how to do this (it had been puzzling me for quite some time how you'd gotten the two different screenshots...). It turns out there are two ways that you can instruct Windows to align shortcut keys in a drop-down menu.
The first (and probably most standard) way is to insert a tab character (\t) in the string corresponding to the menu text. This produces the bottom example shown in your original question, the one where all the identifiers are left-aligned and some overhang slightly. This is the standard in almost all Microsoft applications, and the only option that I knew existed until a few minutes ago.
Sample resource string: &Print…\tCtrl+P
The second way is to replace that \t escape sequence with \a in the resource string (which, yes, strangely enough would normally indicate an alert bell). This causes Windows to right align all of the shortcut key sequences in the menu, producing the example illustrated in your first screenshot. This does produce a menu that uses screen space more efficiently (it's smaller), but this comes at the cost of a neat alignment of each of the shortcut key sequences down their left-hand margins, which I think makes for slightly easier readability.
Sample resource string: &Print…\aCtrl+P
So if you want your menus to look like the second example in your original question (Yes, I've confusingly arranged my samples backwards. Sorry), you need to delimit the shortcut key sequence with a tab character (\t) in the resource file containing your menu item text strings.
The strange thing is that you claim to be using .NET WinForms, which handles all of this automatically (saving you from the pain of messing with resource files). I know for a fact that it inserts tab characters, and all of the menus I've ever seen it generate do look like your second example.
The best thing to do is switch your menu to the old MainMenu control included with earlier version of the .NET Framework. (To do this, you'll probably have to right-click on the Toolbox and add the control manually—it isn't there by default on later versions of Visual Studio.) This will ensure that you see the alignment behavior you expect, consistent with all of the standard Windows applications like Notepad. It also produces menus that look like the native operating system menus (in Vista and 7, they are painted blue) rather than the amateur-looking owner-drawn menus produced by the MenuStrip control that are completely out-of-place in modern versions of Windows.
Microsoft's official documentation does confirm that the MainMenu control is still supported for future use, so there's no reason to fear using it in your apps. I highly recommend everyone use this instead:
Although MenuStrip replaces and adds functionality to the MainMenu control of previous versions, MainMenu is retained for both backward compatibility and future use if you choose.
They are 'right' aligned, as you can see. (No pun intended).
This is default behaviour for a menu. You'll need custom drawing to do it differently.
Every OS has it's particular look and feel, and I guess that you have to have pretty good reasons not to honor how every other application on the windows looks. I guess you will either drop the issue, or will extend the menu with OwnerDrawn items.
Here is the overkill article on the subject.
What do you think is the best way to present a hierarchical list of functionality to users within your traditional WinForms application? (A menu system - Assume functionality can be split into a small number of modules and sub-modules but with no fixed depth in terms of those sub-modules).
Do you like the traditional drop down menu system, ribbons, docked toolbars, a treeview approach or any other innovative ideas?
An important thing to consider in your design is Usability vs Discoverability.
The best solution depends strongly on who you users are. The UI requirements for a kiosk application for tourists in a city centre are very different to those for a control screen at a power station...
I often have a toolstrip docked on top for those functions that is most used. And all other as drop down menues with hotkeys set.
If I have a list that can contain different types of items I use a bottom docked toolstrip that change its content depending on the selected item in the list. That way I only have buttons/icons that is relevant for the task and not a bunch of disabled buttons irritating the view.
I also add a context menu for the items that automagically fills with the same choises as the bottom toolstrip. That way I give a faster way to get to the "action" without having to move the mouse down to the bottom of the screen.
I really hate the ribbon-thing (as a user) so I dont use it as a programmer in my projects.
In my opinion the best way is to make sure everything can be done in several ways.
Menus
Keyboard shortcuts
Toolboxes ...
So the user can choose it's way around.
What I really like to see in more application is that a menu or option is directly attached to the selected item (control) a user is looking at. And of course the menu is in context with the given content.
I have implemented this in my open source project Monex and I really like using it myself. Just look at this screenshot.
You could always opt for the increasingly ribbon control. Microsoft/Office interfaces have a habit of becoming the user's expectation of norm (eventually).
Menubars, toolbars, and Ribbons are used for commands, where the user selection of an item acts on a data object displayed in the window or the application as a whole. Which one you use depends primarily on the number of commands in your app.
Toolbar alone: About 20 or fewer commands. Provide both icons and text labels for each command button. Represent the hierarchy by separators. Have no more than two levels –flatten your hierarchy accordingly.
Menubar with toolbar: Over about 20 but less than about 1000 commands. Up to twenty menu items on a single menu (using separators) is generally better than cascade menus –flatten your hierarchy accordingly. Common commands should have accelerators. Generally limit your toolbar to no more than 30 of the most commonly used commands, primarily commands otherwise only accessible from within a dialog box. Consider not having toolbar controls for menu items that have accelerators –one good means of expert access is often sufficient.
Ribbon: Over 1000 commands. A Ribbon is little more than putting different menubars-and-toolbars on separate tabs. To work well, the tasks associated with each tab (the top of your function hierarchy) should be non-integrated –users relatively rarely switch from one to the other. The Ribbon is also tends to be more effective for promoting discovery of advanced features at the price of discoverability and efficiency of basic features.
Check if items in your function hierarchy may be better represented as attributes rather than commands. Commands carry out a process, such as Open, Find, and Copy, while attributes change specific characteristics of something, such as Font, Size, and angle of view. Attributes are set by field controls within your window (e.g., text boxes, check boxes, and dropdown lists) rather than menu items, toolbar controls, or Ribbon controls.
A window-full of such field controls (or other representations of data objects) is a content block. Tree controls may be used to control what content block is shown. Like tab controls, they are preferred over multiple windows when the user frequently switches among the content blocks and does not compare content blocks. Trees are preferred over tab controls when the amount of content will not fit in a single row of tabs.
Do not have any empty nodes in your tree. Anything the user clicks on should display a full pane of content –flatten your hierarchy accordingly, even going to the extreme of using a list box rather than a tree.
If users tend to select one content block, complete a task there, then leave your app, then consider a “home” page displaying a full-page menu of all the content blocks, possibly spatially arrange according to your hierarchy, each accessible with a single click.
In my opinion there is no definite answer to your question. It always depends on the menu you are presenting to the user and the users that are expected to use the application
A menu with standard/common functionalities is probably best presented Office style meaning drop down menus or the new Ribbon style.
A menu with custom functionality and, as you state multiple modules and submodules with different depths, is often best presented as a TreeView-like menu.
Looking from the point of the user, a typical user will do just fine with a standard menu whereas a more advanced user won't mind more advanced features like keyboard navigation or possibility to hide/show the menu or dock it to the other side of the window.