I wanted to change the code editing keys for "move to start of line" and "move to end of line" to be Cmd+Left and Cmd+Right as they are for most other apps on Mac. Home and End are the mappings in the Dreamweaver Standard file, but those keys are not on laptop keyboards and Cmd+Left and Right are the conventions these days anyway (yes I know using the Fn key I can reproduce Home and End but I want consistency with everything else I use).
I created a duplicate shortcut set using the Dreamweaver UI but when I go to change a shortcut or add a new one using the DW UI, it will not recognise the arrow keys. For example pressing Cmd+Left does nothing and it's not recorded.
So, I went and edited the the shortcut file and put in the changes myself, but when I launch Dreamweaver it ignores those changes.
Here's the shortcut file changes I made. Note I removed Cmd from Move and Sel Word leaving Opt as the modifier (agai the Mac convention) and then used Cmd for MoveStartLine, MoveEndLine, SelStartLine and SelEndLine.
But When I launch DW these key settings are ignored. In the UI they are blank.
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveWordLeft" keys=""/>
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveWordLeftMac" keys="Opt+Left"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveWordRight" keys=""/>
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveWordRightMac" keys="Opt+Right"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelWordLeft" keys=""/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelWordLeftMac" keys="Opt+Shift+Left"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelWordRight" keys=""/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelWordRightMac" keys="Opt+Shift+Right"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveStartLine" keys="Cmd+Left"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_MoveEndLine" keys="Cmd+Right"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelStartLine" keys="Cmd+Shift+Left"/>
<SHORTCUT ID="DWShortcuts_HTMLSource_SelEndLine" keys="Cmd+Shift+Right"/>
Can anyone tell me how to achieve remapping these shortcuts?
Since CMD+Left/Right are the native keyboard shortcuts for going to the beginning/end of the line, you can achieve the desired result by removing the customized keyboard shortcuts in Dreamweaver.
For each of the following, select it, and then click the '-' (minus, "Remote item") button:
Code Editing > Move word left
Code Editing > Move word right
Document Editing > Go to Next Word
Document Editing > Go to Previous Word
Thank you so much! My error was only making these changes for Code Editing. I didn't even notice the Document Editing section. And yes, just deleting the Adobe overrides is enough to get the native behavior I want - including cmd+shift+left and so on. Thanks again.
This fixed Code View beautifully. I just deleted all the whacky Dreamweaver shortcut keys for moving the cursor, and now I can type in Code View without frustration. (I also changed Preferences to Command+Comma while I was at it.) The keys are no longer idiosyncratic. They all work as normal and expected. Finally! I'm a lot less angry at Adobe now.
However, Preview mode is still whacked out. The normal ways of moving the cursor don't work, and it is frustrating banging around to figure out the idiosyncratic Adobe way of doing things. It's like having to remember to type a B when I want an F. I'm not sure what "document editing" applies to, but it even though it helps with Code View, it doesn't fix Preview mode. If there were a way to bring sanity to Preview mode's cursor keys, I'd stop looking for a replacement for Dreamweaver and think about an update to CS6.
I know what you mean but I'm just glad to have received this advice to get native behavior in editing. It's very strange to me that they don't offer a set for Native Mac OS X but they do offer a set for BBedit (for example). Plus, their remapping UI fails in a bad way (from a UX standpoint) by simply ignoring any attempt to remap to native. Very odd.
That said, I haven't been able to get Cmd+uparrow or CMd+downarrow to work (top of doc and bottom of doc) but I'll take this small step for word and line movement and selection. I noticed that DW CS6 is not 64bit so maybe there's some hope when it finally does go 64bit (CS7?) that more Cocoa behavior will be available.
(to be clear, I don't think 64bit matters per se for an app like this, but there's an assumption that maybe some Carbon is stil being used and a move to 64bit will require Cocoa and thus more native behavior will come with that rewrite. However, being 32bit does mean that 32bit libraries have to be paged in by OS X. i.e. it does waste resources)
The Collins Law of Motorcycles says: "The size of the motorcycle is directly proportionate to the size of the biker's belly."
Perhaps there is something similar afoot here. Could it be that the qualify of the software is inversely proportionate to its price? Adobe and Microsoft software is the most expensive, and Onyx is completely free. Need I say more? Using the native UI takes zero design and development time. Implementing a screwy one requires time to misdesign it and misimplement it. They could do less work, charge the same amount for the software, and make more profit, just by leaving well enough alone. They would also please a lot of customers and sell lots more stuff. Instead, they choose to frustrate their customers.
Now they might argue the program has to run on Windows, too, but that means they have a UI that pleases no one. It's also a sham argument, because they do allow us to choose different keyboard layouts, just not the one that makes sense. The way this software is structured, there is no reason a Mac user can't have a Mac UI while a Windows user has a Windows UI.
Using a native UI does take time. It has to be coded, tested, documented, and supported. It's also more likely that the "idiosyncratic" keys pre-dated a standard Cocoa approach. I presume most Adobe Mac apps were Carbon apps first.
I don't believe programmers sit at their workstations, or in design meetings, and choose to frustrate their customers rather than please them. But large-scale software development has a lot of other pressures and you also have large companies here with dominant software that are trying to not only hold on to their profts but continue to grow them. That gets harder and harder to do over time (unless they're brave enough and innovative enough to disrupt themselves).
I don't want to appear to be an Adobe fan because there is a great deal I dislike about their practices, I just think you're more likely to get an incremental enhancement or a workaround by pouring a little honey vs scorn.
So, again, I am very grateful to have received the advice I did here to get native key bindings for movement and selection in the editor. And yes I also hope they add "Mac standard" or "OS X standard" as a selectable key set in a future update.
The whole idea of the native UI is that they don't have to code it or test it, because it is the native UI. It's built in. An idiosyncratic UI requires building a UI from scratch to overlay the one that is already there. The fact that we can delete Dreamweaver's overrides in the editor to get native functions shows that Dreamweaver is remapping it. It's more work to overlay it than to leave it alone. In other words, it is much less work to be normal than it is to be weird. Documentation and support is easier, because there is transfer of learning from other applications. If the application uses SHIFT+F8 for delete, they have to document it. If it uses the delete key to delete, it requires no documentation.
I have only been a Dreamweaver user since 2005, so perhaps I'm being impatient. After all, Cocoa has only been around for 12 years.
From previous correspondence with Macromedia and now Adobe, I have learned that they are overriding the native UI with an idiosyncratic UI for the benefit of legacy users and for consistency between the Windows and OS X platforms.
Keeping the same UI on both Windows and OS X makes no sense, because then a dual-platform user has to contend with four UIs: Windows, Windows-flavored Adobe, OS X, and OS X-flavored Adobe. Using the native UI means there are only two. If you are using Windows, you are using Windows, and if you are using OS X, you are using OS X. If you use both, you are fluent in both, and adding an Adobe UI adds no benefit.
The number of legacy users is not increasing. Legacy users advance to other positions, they retire, they die. No new legacy users are being born. Even if all legacy users are incapable of dealing with an application that is consistent with its operating system and are completely unfamiliar with non-Adobe applications, Adobe will suffer.
Right now there is not much competition for Dreamweaver, so they can make this a low priority if they choose. The status quo is not eternal. The UI is the interface between the software and the customer's wallet. Someday, someone is going to come up with a product that can do everything Dreamweaver does, but with a better software-wallet interface, and then Dreamweaver will lose market share.
All this hullabaloo is for Adobe's benefit. Seven years of honey didn't work, so now I'm trying scorn.