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.
Related
I've got a pretty complex question for any Maya coders...
I want to utilize a drop down menu similar to that of the cmdScrollFieldExecuter's [script editor's] "Show Tooltip Help". It looks like a window that has been appended to the bottom of the inputted text with a feedback of all relative commands or strings.
Does anyone have experience with appending a similar textbox/ window/ menu to typed input, and if so, can you toss me in the right direction?
Note: I am not talking about "optionMenu".
Alternatively, is there a way to get cmdScrollFieldExecuter to reference a different array or set of strings?
A complete port of that won't be possible in vanilla Maya - You'd need to use python and QT because the built-in GUI objects (such as TextField) don't fire any events on keypresses so you won't be able to live-update as the user types.
You can almost fake the visual appearance with a window whose title bar is set to off. Use a formLayout to dock a TextScrollField inside it. You'll need to hack up some way of dismissing it since it won't have a close box -- you could put it on a timer or add an invisible button covering the whole thing which closed the window when clicked
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
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.
I'm looking to add a 'close' button to my main window's menu. An example can be found in the picture here: http://ifyoucodeittheywill.com/img/crimson-editor.png
(So, there's the normal close button in the window caption area, but, there's also a close button in the window's menu bar -- on the far right).
I'm using basic win32 API's, though an example using MFC would also be fine.
Does anyone know how to do this?
Thanks,
Andrew
These buttons usually come with MDI windows. However I'm pretty sure the depicted application uses either its own, or more probably some advanced third party toolkit. Because, to be honest, what the Windows API and MFC (which is just a classed wrapper around the windows API) give you for GUI programming is unbareably limited.
If you want to design neat UIs steer clear from MFC and better have a look at something like Qt, wxWidgets or the like.
A really simple way of doing this is to use a regular menu item, using AppendMenu, but use the following flags:
MF_BITMAP with a close button bitmap, or MF_OWNERDRAW or to draw it yourself
MF_HELP (aka WM_RIGHTJUSTIFY), a not-very-well documented flag, which will justify the item to the right.
Here's one reference to MF_HELP that I found on msdn - it's actually about using the Win32 API to right-justify a menu item, but using Visual Basic.
MF_HELP (defined in winuser.h) is something of a holdover from Win16 days, back then, the convention was to right-justify the Help menu item, so it would stand apart. It was 'renamed' - an additional #define added with the same value - to WM_RIGHTJUSTIFY around Win95.
Note that bitmap menu items aren't accessible (eg. to users that are relying on a screenreader to read out where they are on the screen); if taking this approach, then at least add a regular 'Close' menu item elsewhere in the menus (eg. under File), so that a user doesn't have to rely on this item, and can also close it through usual means. Also be sure to implement the Ctrl-F4 shortcut, which is what most applications that support multiple documents or tabs use to close the current item.
By all means do not try to create this behaviour yourself. This is functionality that you get "for free" if you are using the MDI architecture of MFC. The close button "next to the menu" as you call it closes the active MDI child window. If you are not using the MDI architecture then there is no point in trying to add a close button there. Can you explain if you are using the MDI architecture?
When designing a form I have the option of putting a close button at the bottom of the form. The form will also have a close form "x" button in the upper right corner of the window as provided by winforms.
Based on the principle of "There should be one and preferably only one obvious way to do it" I was thinking the close button should be removed because of the forms existing default functionality.
What have the rest of you found in your experience that works best for users or has been the standard for UI setup?
I have done a considerable amount of design work, and I can't say I have heard of the principle of, "There should be one way to do [some task]." In fact, I have heard (almost) the opposite: "There should always be one obvious way to do a task, but additional methods could be used to help different user types." An example of this is the ability to hit the "Save" button to save a document. But, you can also do "File > Save" and you can also hit Ctrl + S. Three ways to do the same task.
Also, if you're programming in a Windows environment (as it appears you are), you will automatically get multiple ways of closing a window. The [X], of course, Alt + F4 is typical, you can setup Ctrl + C, etc. I wouldn't particularly put a close button on the bottom of the form unless it flows with the form's input. For example, if you want to [Submit] or [Close] the form - does that make sense? Would it be better to [Submit] or [Cancel]? Think about what your users are doing and how they are using the form.
Here are some guidelines I follow:
If the form is an application (it was launched directly from Windows), it should probably not have a close button. Users expect to be able to close the application by clicking the X in the top-right corner.
If it is a dialog (it was launched from another window within your application) that simply displays information, it should probably have a close button and you can optionally leave the Windows close button as well.
If it is a dialog that allows the user to edit data it should have a Save or Apply button and a Cancel button but no Windows X. The reason is because it is ambiguous what it means. Should it save the data? Cancel it? Display a dialog asking them what they want to do?
In general I do agree that there should be only one way to do something. The reason is that a reasonable user will have to wonder if they do different things (even if they are named the same). Even if the user discovers they do similar things, they may wonder if they are subtly different.
Of course there are exceptions to the rule. For example, most users understand that the file menu, toolbar, and keyboard shortcuts of the same name all point to the same command.
I think that principle applies mostly to coding (and not for every language, think of Perl!), for UI's usually it's good to have different ways to do things... because it allows you to do things faster.
Think about any common operation like cut or paste, you can use the edit menu, the contextual menu, the keyboard shortcut or even the icons in the toolbar. Try to remove any of those ways of doing it in any application and you'll have hordes of users screaming to get it back.
So here the main principle is to not change what the user expects. Another remark: be consistent, though there might be different ways get access to the same functionality, all of them should work in the same way (I'd be very pissed of if copying with the keyboard shortcut did a different thing than copying with the right mouse button XD).