Closed pascallothar closed 8 years ago
I have never used Mac. According to several documentation, it seems that in the browser it is Mac Control key that acts like Window Ctrl key. Could you try Control+Click and see if it works?
Additionally, could you test whether legacy ScrapBook (current 1.5.13) work on Mac?
Hello, I was wondering if I misled you, so I was googling a little bit to remember how it works on Windows and Linux. Probably the documentations you mentionned were talking about the mapping of the keys themselves of the PC keyboards and the Mac keyboards (meaning hardware), but not about their functionality on the different operating systems.
For example, to copy on Windows, you will use ctrl + C
, where you will use cmd + C
on Mac.
[http://www.howtogeek.com/183636/how-the-command-and-option-keys-work-on-a-mac/]
On Mac,Ctlr + Click
has everywhere the same behaviour than right click
(probably because the earlier Macs had a mouse with only one button (meaning only the "left" click
button)).
Cmd⌘ + Click
will open a link in a new tab behind the current one, if you click a link.
Cmd⌘+ Shift⇧ + Click
will open the new tab & bring it to the front.
Those two behaviors applied to a Sidebar Item would be consistent with the usual Mac behavior. For the moment, Cmd + Click
doesn't do more than Click
alone, and, as I said, is prone to "mistakes".
As you can see, Mac wouldn't have been Mac if they had done things easier and had followed the behavior of others :-)
I have just installed ScrapBook 1.5.13.1-signed.1-signed (Gomita) on my MacBookPro with MacOsX 10.6.8 (last Snow Leopard).
Everything seems to work. Though I didn't test it thoroughly.
"Create MAF" (your add-on version) on a Sidebar Item does NOT work. "Copy Page Info" (your add-on version) on a Sidebar Item DOES work, BUT does NOT work on the full tree (Sidebar -> Tools -> Add-on functions -> Copy Page Info: Arborescence complète).
Disabling Scrapbook, re-enabling Scrapbook X :-)
Could you please check first whether control+click work on Mac? Likeweise, please also check whether control or cmd work on legacy ScrapBook? If possible, check a few more ctrl usage cases mentionerd in the documentation you provided so that we can make sure wehether it's general case or not
Hello Danny,
1°) It seems that I didn't understand why you asked me to try the legacy Scrapbook on my Mac. I thought it was to help you to know if it was working or not on Mac, but, now, I have understood that it was to know its behavior with the Cmd and Ctrl keys. :-)
2°) I said: « I was wondering if I misled you, so I was googling a little bit to remember how it works on Windows and Linux ». I was not sure that I was remembering well the behavior on Windows and Linux, but I was sure of the behavior on Mac, since I use these shortcuts everyday :-) . (And also, I didn't change the default behavior). I remember it was a little bit annoying in the beginning when I migrated to Mac.
1°) The default behavior on Mac for Ctrl+Click
(system wide) is to open the contextual menu (Same behavior than if you have a mouse with a right-click
(the earlier mouses branded by Mac had only one button)).
For Firefox, TabMixPlus allows you to change the behavior of Ctrl+Click
from a°) the default contextual menu; to b°) force opening in the current tab the stuff (depending on the other settings) that should open in an new tab.
There is no possibility to change the other behaviors of the key shortcuts like Cmd+Click
or others from the Options set-up (perhaps is it possible with about:config
?).
One of the two links I gave you [http://apple.stackexchange.com/questions/170731/how-to-open-link-in-a-new-tab-via-shortcut-in-chrome-on-mac] is for Safari on Mac (the question was asked for Chrome on Mac, but the answer was mistakenly given for Safari on Mac). On Safari, you can change the default behaviour (but it will always use Cmd
(actually, you will only toggle new tab / new window in new window / new tab and background tab / active tab in active tab / background tab)), not on Chrome (perhaps if you edit the config files?). In this link, you will see: « Cmd + Alt + Click
= Opens a link in a new window » and « Cmd + Alt + Shift + Click
= Opens a link in a new window, and makes it the active window », but it is SPECIFIC to Safari.
BUT « Cmd + Click
= Opens a link in a new tab » and « Cmd + Shift + Click
= Opens a link in a new tab, and makes it the active tab » are common to Firefox, Chrome, Opera (I have never used Opera before, but I have just installed it to check the behavior) and are not configurable and are the DEFAULT behavior of Safari. They sey also « Remember that Cmd⌘ on Mac is usually equivalent to Ctrl^ on Windows »; I can say that, yes, it's USUALLY true.
Here is an other link [http://www.7is7.com/software/firefox/shortcuts.html] with the shortcuts for Firefox 3.5 and 3.6 for the three major OS. You can see there (and I can confirm it) that on Mac OS X:
Cmd+Click
= Open Link/Bookmark in new Background Tab (as said above, COMMON to all browsers).Cmd+Shift+Click
= Open Link/Bookmark in new Foreground Tab (as said above, COMMON to all browsers).Shift+Click
= Opens Link/Bookmark in New Window, and makes it the active window (Specific to FIREFOX).2°) I will also make you the description of the behavior of the "Finder", of other file explorers or the like.
Click
= select.Double-Click
= open.Cmd+Click
= toggle select/deselect.Shift+Click
= select all the items between the clicked item and the previously selected item.Cmd+Double-Click
= open in a new tab (meaning for a single selected tab).Cmd/Shift+Double-Click
= open in several new tabs (meaning for several selected tabs).See my comment (#23 ).
3°) I have tried again ScrapBook 1.5.13.1-signed.1-signed (Gomita):
a°) In the Sidebar (Gomita):
Click
= Open Item in the Current Tab :-) .Double-Click
= Open Item in the Current Tab (nothing more than simple Click
).Shift+Click
= Select all the Items between the clicked Item and the previously selected Item AND open the clicked Item (only one) in a NEW Tab (How weird!!! An UNCLEAN mixed behavior!!).Shift+Double-Click
= same, but will open the clicked Item twice (in two NEW Tabs).Cmd+Click
= Toggle select/unselect the clicked Item (keeping the others selected) AND open the clicked Item in the CURRENT Tab (How weird!!!).Cmd+Double-Click
= same than Cmd+Click
.Ctrl+Click
= Select the Item and open the contextual menu of the Item(s) (Doesn't open the Item in the tab; the contents of the tabs are not changed).Right-Click
= same behavior than Ctrl+Click
.Ctrl+Double-Click
= nothing more than Ctrl+Click
.Alt+Click
= nothing more than simple Click
.Alt+Double-Click
= nothing more than simple Click
.b°) In the "Manage" window: (actually the behavior is the same than in Scrapbook X):
Click
= Select the Item.Double-Click
= Select the Item and Open the Item in the CURRENT tab.Cmd+Click
= Toggle select/deselect the Item.Cmd+Double-Click
= Toggle select/deselect the Item AND Open the Clicked Item in the CURRENT tab.Shift+Click
= select all the Items between (and including) the clicked item and the previously selected item.
More precisely, if you click an item, it will be selected. Now Shift+Click
a second item. All the items between the first and the second item will be selected. Now Shift+Click
a third item. All the items between the FIRST (not the SECOND) and the THIRD will be selected (The mechanism acts as it will not remember an item as "beginning" when Shift+Click
ed, but only when the last simple Click
ed or the last Cmd+Click
ed and will take for "end" the last Shift+Click
ed. All the previously selected Items will be forgot).
Cmd+Shift+Click
= same, BUT doesn't forget the previously selected Items.Shift+Double-Click
= Same than Shift+Click
, but also open the Clicked Item (only one) in a NEW Tab.Cmd+Shift+Double-Click
= Same than Cmd+Shift+Click
, but also open the Clicked Item (only one) in a NEW Tab.Ctrl+Click
= Open the contextual menu.
More precisely (I am not sure if it is important for something), if you Ctrl+Click
an item which is part of a bunch of already selected items, it will open the contextual menu and keep the selection as is. If you have a bunch of already selected items and you Ctrl+Click
a not selected item, the previous selection will be lost, the contextual menu will be opened and the Clicked Item will be selected.
Ctrl+Double-Click
= nothing more than Ctrl+Click
.Right-Click
= exactly the same than Ctrl+Click
.+ Alt
= the same than these combinations without Alt
.4°) Now to compare with Scrapbook X (Version 1.13.0b4):
a°) In the Scrapbook X Sidebar: (the differences with Gomita's are in bold italic):
Click
= Open Item in the Current Tab.Double-Click
= Open Item in the Current Tab (nothing more than simple Click
).Shift+Click
= open the clicked Item in a NEW Tab.Shift+Double-Click
= open the clicked Item twice (in two NEW Tabs).Cmd+Click
= same than simple Click
.Cmd+Double-Click
= same than simple Click
.Ctrl+Click
= Select the Item and open the contextual menu of the Item (Doesn't open the Item in the tab, the contents of the tabs are not changed).Right-Click
= same behavior than Ctrl+Click
.Ctrl+Double-Click
= nothing more than Ctrl+Click
.Alt+Click
= nothing more than simple Click
.Alt+Double-Click
= nothing more than simple Click
.Cmd+Shift+Click
= same as Shift+Click
.Cmd+Shift+Double-Click
= same as Shift+Double-Click
.b°) In the "Manage" window:
Same behavior than in Gomita's Scrapbook.
5°) In the Firefox bookmarks window:
simple Click
, same behaviour than in the "Manage" window.Double-Click
= Select the Item and Open the Item in the CURRENT tab.If no item is already selected, Cmd+Double-Click
ing an item will open it in a NEW TAB.
Otherwise nothing more than for Cmd+Click
will happen.
If only one item is already selected, Shift+Double-Click
ing it will open it in a NEW WINDOW.
Otherwise nothing more than for Shift+Click
will happen.
Double-Click
will do the same than with simple Click
.6°) I wonder if, this night, I will dream of:
Simple Click
s?Double Click
s?Cmd+Click
s?Shift+Click
s?Or ... of all of them mixed together? :-) Sure, it will be the ... right click! :-)
In both references on the Mozilla Developer Network and W3school, it is a standard that a mouse event with metaKey = Win key on Window = Command key on Mac. There is no specific documentation talking about ctrlKey, but I think it is Control key on Mac since Command key is used by metaKey.
Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key. We don't know why the standard is formulated in this way, but we have to add many additional codes and ac hoc handlers to do the remap for Mac to work use Command key as Ctrl.
Here are still something we need to know:
about:config
in the address bar, and find the value of ui.key.accelKey
.@pascallothar On 1.13.0b8 we implemented a new hotkey system to support cross-platform issues. Welcome to try whether command
key work as expected and whether hotkeys are showed in Mac style.
This is the hotkeys shown on most platform:
This is the hotkeys ought to shown on Mac if it works right:
The answers are for your TWO posts:
In both references on the [Mozilla Developer Network] and [W3school], it is a standard that a mouse event with metaKey = Win key on Window = Command key on Mac. There is no specific documentation talking about ctrlKey, but I think it is Control key on Mac since Command key is used by metaKey.
Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key.
Yes, you are right:
event.ctrlKey
==> Ctrl
key (also noted caret ^
) on Windows, Linux and Mac. Actually, nothing illogical here. Did Mac (actually Windows (see history)) forget to show its difference, here? :-)event.altKey
==> Alt
key on Windows, Linux and Mac ( ⎇
) (on Mac the key is also named Option
and labelled ⌥
).event.shiftKey
==> Shift
key (also labelled ⇧
) on Windows, Linux and Mac (no bad luck there, fortunately :-) .
Those keys are historically quite older (to be precise, they were more widespread among different systems) than the following one (to be precise, the following key was already existing before it was "re-introduced" by Windows and Mac):
event.metaKey
==> On Windows: Windows
key ( ⊞
).
==> On some "agnostic" keyboards, it is labelled Meta
or ◆
to please, for example, some Linux and BSD "fanatic" users.
==> On Mac keyboards, it used to be labelled with an apple icon (
); nowadays, it is labelled Command
, ⌘
or Cmd
.
Actually, if you plug a Windows branded keyboard or a generic keyboard to a Mac, it works immediately and you have to use the Windows
key where you would have used the Cmd
key with a Mac keyboard.
NOTES: 1°) On some "older" systems laking a Meta
key, there were work-arounds using Alt
(or even Space
as a modifier). 2°) Sometimes, Meta
key is named Super
key (although, on other systems like Lisp, Meta
and Super
are different keys), but, in spite of that, it doesn't fire a event.superKey
event, but the event.metaKey
event. Yes, in computer sciences, the things you could think to be the simplest things are everything but simple :-) .Maybe it's custom that Mac users use command as Ctrl in Windows, but it already a standard that in the browser javascript system it's Command = metaKey = Win key. We don't know why the standard is formulated in this way, but we have to add many additional codes and ac hoc handlers to do the remap for Mac to work use Command key as Ctrl.
Yes, the lack of coordination and of standardization is a nightmare for informatics (and for the world in general (kind of Babel tower)).
As I understand things from the stuff I have read in the past (and today), Shift
was already used by typewriters; Ctrl
(as its name stands for), Alt
, and other control keys and control characters were used by the teletypewriters, the terminals, the terminal emulators and the earlier keyboards of different electro-mechanical, electrical or computer systems. Xerox begun the GUI operating system, followed by the Apple Macintosh, followed by Microsoft Windows. They reused features of the legacy systems, but they were following their own way of doing things. The portability of the applications was not their preoccupation at that time. As for the war of document and media formats that happened at those times, the war between Mac and Windows was not to ease the standardization, which occurred much later because of the needs of industry. Fortunately, nowadays, a lot of the most common shortcuts have perhaps a different modifieR key, but the modifieD key is the same. Imagine if Mac would use Cmd+Q, Linux Ctrl+D and Windows Ctrl+C to copy. We could of course imagine worse: that the British oranges would be American bananas and that British bananas would be American oranges. Or that the words "on" and "off" would have inverted signification in the two countries. Yes, it's almost that with the Cmd
and Ctrl
behaviors :-) .
Is Control key on Mac naturally work as a key for context menu?
No. Ctrl
on Mac, as on Windows, is a modifier key, meaning that if you push it alone, nothing happens (USUALLY, to be precise! Because some rare applications will use a modifier key as a simple key (hitting once or twice Alt
(or and other modifier) or keeping it pushed more than 2 seconds for example), but I don't remember any example for the moment. It is also possible to use a simple key as a modifier (for example, when Space
is down, hitting K). Actually, this is not specific to Mac).
But Ctrl+Click
is the equivalent of Right-Click
(As I said above and in other posts, Mac used GUI and mouse with only one click before MicroSoft created Windows, so, the contextual menu was triggered by Ctrl+Click
. Only later, Mac introduced a "Secondary Click" (name of the right-click in the Mac world, probably to not use the same word than Microsoft)).
Besides Cmd
and Shift
, Ctrl
and Alt
are used for shortcuts also, but they are not so many than the shortcuts build with Cmd
== Meta
. [Mac keyboard shortcuts https://support.apple.com/en-us/HT201236] will give you the shortcuts used system-wide and also the shortcuts used by the applications branded by Mac and integrated in their distribution. The third party applications will try to mimic the behavior of the Mac "integrated" applications (e.g.: Firefox shortcuts are usually the same than Safari's (Mac "integrated" web browser)).
Here are some links concerning what I said above in the present post:
Could you help me check an Firefox config on Mac? Type about:config in the address bar, and find the value of ui.key.accelKey.
ui.key.accelKey == 224
In the "Version History":
Functionality changes:
- Improve cross platform hotkey support, especially the command key support and the key symbol style for Macs.
- Allow customized hotkey combination in the user options.
I don't see that in the Options GUI? Is it in a configuration file, then?
.../... and whether hotkeys are showed in Mac style. .../... This is the hotkeys ought to shown on Mac if it works right:
No. Here is what Mac users ACTUALLY see:
For me and aware people :-) , it's not a problem, but very probably, most people would have no clue of what Meta
is!
Could you try the hotkeys for DOM erasor and for HTML editor and see whether Command or Ctrl key work?
Ctrl
or Cmd
in DOM Eraser itself.F9
is used BY DEFAULT system-wide to display on the Desktop the thumbnails of all the windows open or minimized (myself, I use 4-fingers gesture on the trackpad), you need to:
"System Preferences ..." -> "Keyboard" -> "Keyboard Shortcuts" -> "All windows (F9)" -> uncheck the checkbox or change the default value.Right-Click
will isolate, but will also open the "contextual menu". It's not a big problem, since it is easy to close the "contextual menu" and there are also other hot-keys to isolate. Is it the same on Windows?x
, "Find in the page ..." bar will open with x
written in it. It's also the default behaviour when not in Scrapbook X DOM Eraser mode.
Now, if some text were already selected before entering in Scrapbook X DOM Eraser mode, hitting w
will widen as expected, but almost as soon, a new tab will be opened with the selected text searched on Wikipedia, which is the behavior when not in Scrapbook X DOM Eraser mode (because I have installed an add-on doing this).+
, I need to hit Shift
+=
(=
with Shift
down) or Caps_lock
+=
(I mean (as on Windows): with Caps_lock
"ON", not really hit). Besides of that, if I hit Caps_lock
+Shift
+ =
, I will write =
(same as if I hit simply =
).
In Scrapbook X DOM Eraser mode, surprisingly, Shift
+=
will work as w
does. Probably because there is no hot-key defined for Shift+=
.
Surprisingly, Caps_lock
+=
will not work. It will open the "Find in the page ..." bar with +
written in it. (And Caps_lock
+Shift
+ =
will open the "Find in the page ..." bar with =
written in it). Why do I say "surprisingly"? To write a 6
, I need to hit Shift
+ §
or Caps_lock
+§
. So to Set to Header Level 6, because Alt+6
is not directly accessible, I need to use Caps_lock
. So I need to hit Alt
+ Caps_lock
+ §
. And Alt
+ Shift
+ §
will not work, it will write å
. So it would have sound more logical that Caps_lock
+=
had worked and not Shift
+=
.c
to colorize, it is colorizing, but soon after this, the page will change. I have understood that hitting c
in a GitHub page will open a page for a new issue. But all the annotations will be lost. It's better to be known.F10
is used BY DEFAULT system-wide to display on the Desktop the thumbnails of all the windows open or minimized OF the current APPLICATION, you need to:
"System Preferences ..." -> "Keyboard" -> "Keyboard Shortcuts" -> "All application windows (F10)" -> uncheck the checkbox or change the default value.Ctrl+M
doesn't do anything. With the Firefox add-on [Menu Wizard https://addons.mozilla.org/fr/firefox/addon/s3menu-wizard/], I can see that Ctrl+M
is used by key_toggleMute
, but there is no menu entry for it!!! Very weird! I unchecked this hot-key to disable it. Even after restarting Firefox, Ctrl+M
doesn't do anything in Scrapbook X HTML Editor mode or not!!! But I am able to Clear Format from the contextual menu. Ctrl+M
isn't used by the system neither. I wonder if key_toggleMute
is not some unused relic that was used to toggle the audio Firefox-wide before the implementation of loudspeaker icons on every tab to toggle mute/unmute the audio output of the tab. So, perhaps is Ctrl+M
caught by this relic and "lost in the vacuum"? (EDIT: Very seldom, it works!!!!! So I tried an external American layout keyboard, but it's the same unstable behavior).[
and ]
, I need to hit Alt+Shift+(
and Alt+Shift+)
, so I am unable to Alt+[
and Alt+]
(to Outdent or Indent). With the American keyboard, of course, it works fine..
and /
, I need to hit Shift+;
and Shift+:
, so I am unable to Alt+.
and Alt+/
(to Align Right or Justify). With the American keyboard, of course, it works fine.Alt+M
, the behavior is different, not good (Some change in the layout of the text, but not the expected one). As expected, same bad behavior with the American keyboard.In the Options dialog, "Show the Sidebar" == Alt+K
works.
The newly implemented "Menu" == Alt+C
does nothing. Which "Menu" is it?
-
which will not work anymore but only open the "Find in the page ..." bar with -
written in it.Cmd
key are already used by Firefox. When one of these combinations is successfully passed by Firefox to Scrapbook X HTML Editor, the menu bar will blink once (e.g.: Firefox use Cmd+B
to "View" -> "Sidebar" -> "Bookmarks". When you hit Cmd+B
while in Scrapbook X HTML Editor mode, "View" in the Menu bar will blink once in blue and then the selected text in Scrapbook X HTML Editor will be styled in bold). Fewer other combinations are also used by the system or system-wide, but will not be passed (I am not sure if it is for all of them) to an application, so not to Firefox and, a fortiori, not to Scrapbook X HTML Editor.Cmd+Shift+C
is used system-wide by Clyppan, a third party application that is an extended clipboard app. While in Scrapbook X HTML Editor mode, Clyppan will work as usually and nothing will happen in Scrapbook X HTML Editor.Cmd+Alt+8
is used by the system to handle the zoom for disabled people. While in Scrapbook X HTML Editor mode, hitting Cmd+Alt+8
will work as usually and nothing will happen in Scrapbook X HTML Editor. I don't use this feature, so I go to "System Preferences" to disable it. Now it works in Scrapbook X HTML Editor as expected.Cmd+M
for Clear Format has the same bad behavior than Ctrl+M
with 1.13.0b7. If Firefox would have not passed Cmd+M
to Scrapbook X HTML Editor, Firefox would have kept it for itself and minimized the window, but it didn't. So I can conclude that this bad behavior has nothing to do with a certain relic (as I thought), but that Scrapbook X HTML Editor has caught Cmd+M
(or Ctrl+M
in 1.13.0b7), but didn't handle it properly to trigger Clear Format.As you can see, you had a good idea in allowing customized hotkey combination in the user options.
NOTE: I didn't say that it is bad to use Ctrl
on a Mac, but that:
Ctrl+LeftClick
doesn't work the way you thought (see above).Ctrl+"key"
works, but is often not consistent with the shortcut of an other application using the same or a similar function and that would use Cmd+"key"
. For app or add-on specific functions, there is no problem to use Ctrl
or Alt
or Shift
or Cmd
or even all of them together to implement a shortcut. Actually, they are often used by Firefox add-ons when it comes to implement novel features. And they will have less chance to conflict with other shortcuts, since the canonic shortcuts very often use Cmd
.Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut Cmd+?
) like the one in Scrapbook X DOM Eraser mode?
I have looked up the usage of shortcuts in different HTML editors on the Mac OS X platform (iWeb, Komposer, BlueGriffon, Adobe Brackets, Adobe Dreamweaver, SeaMonkey Composer, Amaya). There is no real standard usage, only some canonical common shortcuts and some others poorly shared (As you can see once more, you had a good idea in allowing customized hotkey combination in the user options). When I will be able to access the "customized hotkey combination in the user options", I think I will choose (But I don't say it is the best or the only way to make a default usage on Mac. I believe that people would choose according to the app they are used to work with) the following customization (so, I give it only for simple info):
F10
== "switch html editor" == Same as SB Windows version^Q
== "Quit html editor" == Not implemented ( ⌘Q
could quit Firefox)⌘?
(actually ⌘,
because of my keyboard layout) == "Help" == Not implemented⌘S
== "Save the page" == Same as CURRENT SB Mac version⌘Z
== "undo" == Not implemented⇧⌘Z
== "redo" == Not implemented^⌘Z
== "clear undo history" == If implemented (if useful?)^N
== "clear liNks" == Same as SB Windows version^M
== "clear forMat" == Same as SB Windows version⌥⌘I
== "Insert or edit source" == Same as CURRENT SB Mac version⌘B
== "switch Bold" == Same as CURRENT SB Mac version⌘I
== "switch Italic" == Same as CURRENT SB Mac version⌘U
== "switch Underlined" == Same as CURRENT SB Mac version⌘K
== "switch strucK-through"⌘↑
== "switch superscript"⌘↓
== "switch subscript"⌘+
(actually ⌘=
because of my keyboard layout) == "increase font size"⌘0
== "restore font size" == Not implemented⌘-
== "decrease font size"⌘E
== "set tExt and background color..." == Same as CURRENT SB Mac version⌥[
(actually ⌥(
because of my keyboard layout) == "increase indent"⌥]
(actually ⌥)
because of my keyboard layout) == "decrease indent"⌥←
or ⌥L
== "align Left"⌥→
or ⌥R
== "align Right"⌥↑
or ⌥M
== "align center (Middle)"⌥↓
or ⌥J
== "Justify"I hope it will help you. Pascal
@pascallothar We need your help to get it work right.
Please download and install the .xpi file in this test version (you probably have to set xpinstall.signatures.required to false in the "about:config" to make it installable on your Firefox). If it work correctly, an alert window will prompt and report your OS when you restart your Firefox like this:
Please report the text content or the screenshot image. We need this information to fix the OS detection issue on Mac.
If you have multiple Mac notebooks in different versions, please try all of them as possible.
I have only one Mac: It's a laptop: MacBookPro with Mac OS X 10.6 (also named "Snow Leopard"), 10.6.8 precisely.
xpinstall.signatures.required to false was already needed to install 1.13.0b7 (or b5 or something, I don't remember)
Question: I suppose that you DID know that Scrapbook X DID already detect Mac (because it was using Cmd key in the Manage window). Didn't you? I prefer to tell you it, to avoid you extra-work.
Here is the second test version. Please check:
Notes:
Ctrl+A
(Select all), Ctrl+C
(Copy), Ctrl+X
(Cut), Ctrl+V
(Paste), Ctrl+Z
(Undo), Ctrl+Shift+Z
or Ctrl+Y
(Redo), etc, are already provided natively by Firefox. Please check whether they actually work or not.Whether key names are shown in Mac style on Macs.
Yes, now, they are.
Actually, the +
sign between the keys are usually not print, but IMHO, it doesn't matter.
Whether the default behavior of shortcut keys are still not skipped. (e.g. right-click isolate for DOM Eraser shows a context menu)
Actually, except for (1) and (2) below, everything is OK.
w
works now perfectly in 1.13.0b9.2-shortcuttest.c
works now perfectly in 1.13.0b9.2-shortcuttest.-
was working perfectly in version 1.13.0b7.
-
written in it.Nothing else have changed since 1.13.0b9 (see in the post above for the detailed feedback). So, in 1.13.0b9.2-shortcuttest:
Right-Click
will isolate, but will also open the "contextual menu". (2)Caps_lock
is IMHO not a real issue, since the hot-keys are now customizable.Cmd+M
for Clear Format now works perfectly in 1.13.0b9.2-shortcuttest.Alt+M
for Align Center now works perfectly in 1.13.0b9.2-shortcuttest.All the others things were already working the way expected to be.
Whether customization of HTML editor shortcut keys via the options dialog works right.
The default size of the Options Dialog is different than it was. It's totally collapsed for several tabs, but, because I was able to resize it, it is OK. But, for the tab of the shortcuts, I couldn't access all the shortcuts, because the dialog would need more height than my screen. So I would need to find on my disk the Scrapbook X configuration file and edit it by hand. But I didn't find it. Here are screenshots of the Options Dialog.
1st tab as it opened the first time:
2nd tab was already at maximum height, which is NOT ok:
3rd tab:
4th tab at maximum size is OK:
5th tab: As you can see, even if resized very high, it will not show everything without a scroll bar.
6th tab: Same comment as for 5th, but you can see also the horizontal scrollbar. Perhaps it can help you to see how to fix the problem of the 2nd tab, which has no scrollbar, but perhaps would need one.
I have edited the hot-keys in the 2nd tab. They don't update in the contextual menu nor do they update in their behavior. So I restarted Firefox. Now it works.
For the inaccessible hot-keys and for those of DOM Eraser, I have tried to find a config file, but I could not find it!
When HTML Editor mode is on, Ctrl+A (Select all), Ctrl+C (Copy), Ctrl+X (Cut), Ctrl+V (Paste), Ctrl+Z (Undo), Ctrl+Shift+Z or Ctrl+Y (Redo), etc, are already provided natively by Firefox. Please check whether they actually work or not.
Yes, they work (Cmd for Mac of course).
We probably cannot solve the issue that system wide hotkeys overwrites our hotkey since systemic hotkey takes precedence. The only way is to modify the system hotkey or to modify our hotkey to prevent a conflict.
Actually, it is not even desirable that system wide hot-keys would be overridden. I was only making a complete feedback of the behavior for a better understanding. And to report that some hot-keys chosen by Scrapbook were already taken by the system. And since the hot-keys are now customizable, it should not be seen as an issue anymore.
On the page of the current version, I see:
Customizable DOM Erasor shortcuts. (Only via user perference)
I cannot find out how to customize them. What and where is this "user preference"?
The newly implemented "Menu" == Alt+C does nothing. Which "Menu" is it?
Actually, in "HTML Editor" mode, it writes only ©
, which is the default behavior if there is no shortcut defined.
I cannot find out how to customize them. What and where is this "user preference"?
It means Firefox user preference, which are all available in about:config
, and some of them are available in the GUI options.
Note that the user preference uses the normalized string which could be different from the GUI. If you don't know how to write, you can set a few key combinations (e.g. Show in Sidebar
) in the GUI and see how corresponding user preferences (e.g. extensions.scrapbook.key.sidebar
) changes in the about:config
.
We do not provide the GUI way because we do not encourage a modification on DOM Erasor keys.
Actually, the
+
sign between the keys are usually not print, but IMHO, it doesn't matter.
We'll adjust the accesskey text to be more compatible to Mac style.
Right-Click will isolate, but will also open the "contextual menu". (2)
Please check about:config
and see whether dom.event.contextmenu.enabled
is set to false
. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.
I'm not sure whether Control+Click
is also affected by this setting. You can also test it for Control+Click issues.
On my MacBookPro with a FRENCH keyboard layout, if I want to write a + , I need to hit Shift+= (= with Shift down) or Caps_lock+= ...
If your keyboard has key =
that outputs +
with Shift
hold, it is simply =
or Shift+=
, which is never equivalent to +
for the accesskey system.
Similarly, if your keyboard has a key =
that outputs +
when CapsLock
is active, it's simply =
for the accesskey system.
But we are somewhat lazy. When the DOM Eraser says +
and -
, it actually means Numpad+
or Shift+=
and Numpad-
or -
(hyphen-minus).
- As said in the post above,
-
was working perfectly in version 1.13.0b7.
- But in version 1.13.0b9, it was working as a normal key (not anymore as a hot-key), meaning that it will open the "Find in the page ..." bar with
-
written in it.- Now, in 1.13.0b9.2-shortcuttest, it works the same (wrong) way as it was already working in 1.13.0b9. (1)
Please check what keys are actually pressed when you mean -
on your keyboard. Is there a modifier?
And please also check the about:config
and see whether accessibility.typeaheadfind
is set to true
. This determines whether a key fires a search, and it seems to block certain accesskeys from working in some unclear situation.
But, for the tab of the shortcuts, I couldn't access all the shortcuts, because the dialog would need more height than my screen. So I would need to find on my disk the Scrapbook X configuration file and edit it by hand. But I didn't find it. Here are screenshots of the Options Dialog.
I really have no idea why it works so on your computer. All option tabs are written in the same way and there should be scrolls for the hotkey tab just like other tabs do if it works as expected:
A guess is that it will work so if the total contents overflows your screen, which is ought not to. If it really does, it may be a bug of Firefox.
Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?
Additionally, hotkeys for HTML Editor are also user preferences and are available in the about:config
. You can set them there if the GUI is unavailable for any reason.
Here is the third test version. Please check:
Please check
about:config
and see whetherdom.event.contextmenu.enabled
is set tofalse
. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.
dom.event.contextmenu.enabled
== true
If I have well understood, it is the right value. Isn't it?
I'm not sure whether
Control+Click
is also affected by this setting. You can also test it for Control+Click issues.
Could you be more explicit?
On my MacBookPro with a FRENCH keyboard layout, if I want to write a + , I need to hit Shift+= (= with Shift down) or Caps_lock+= ...
If your keyboard has key = that outputs + with Shift hold, it is simply = or Shift+=, which is never equivalent to + for the accesskey system.
Similarly, if your keyboard has a key = that outputs + when CapsLock is active, it's simply = for the accesskey system.
But we are somewhat lazy. When the DOM Eraser says + and -, it actually means Numpad+ or Shift+= and Numpad- or - (hyphen-minus).
Thank you. It helps me to better understand how the French keyboard layout works.
Indeed, by playing with the customization fields, I can see that, on my keyboard, even if I have to hit (
with Shift
down or (
with Caps_Lock
to write a 5
, the customization field will be filled with 5
when I hit (
with or WITHOUT Caps_Lock
.
Meaning that I will never be able to define a shortcut Alt+(
(to replace Alt+[
which is not accessible with my keyboard), but only Alt+5
(that is already used).
But Alt+)
is possible ()
with Shift
down writes a °
).
Meaning that the mapping of the French keyboard layout to the "access-key system" use sometimes "uppercase", sometimes "lowercase", and that independently of Caps_Lock
.
- As said in the post above,
-
was working perfectly in version 1.13.0b7.
- But in version 1.13.0b9, it was working as a normal key (not anymore as a hot-key), meaning that it will open the "Find in the page ..." bar with
-
written in it.- Now, in 1.13.0b9.2-shortcuttest, it works the same (wrong) way as it was already working in 1.13.0b9. (1)
Please check what keys are actually pressed when you mean - on your keyboard. Is there a modifier?
No, no! No modifier. It is the hyphen-minus
.
extensions.scrapbook.key.domEraser.narrower3
was set to Hyphen_Minus
. I have deleted the _
, setting it to HyphenMinus
. Now it works again (as it did in 1.13.0b7).
Are you sure that it works on your Windows with the string Hyphen_Minus
(with _
)? If it does, Steve Jobs (or somebody else, probably) needs some posthume ears pulling :-) to learn not being different uselessly.
And please also check the about:config and see whether accessibility.typeaheadfind is set to true. This determines whether a key fires a search, and it seems to block certain accesskeys from working in some unclear situation.
accessibility.typeaheadfind
== true
Actually the key fires a search only if it is not defined as a hot-key, so it should not be a problem. As said above, -
was not defined because the string Hyphen_Minus
was not recognized as -
.
Here is the third test version. Please check:
1. Whether the Mac style hotkey text work right.
Yes, it works right. Here are the screen-shots.
2. Whether the scrollbar works in the options panel if the content overflows the dialog window.
Sorry, nothing have changed.
Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?
- Resizing works.
- Mouse scroll works only when the scroll bars show up (which is not an unexpected behavior LOL).
I wonder if it is not related to the pre-defined values of the minimum and maximum size of the scroll bar. If the blue bar-cursor of the scroll bar is to high, the minimum size of the window has to be too high for the height of the screen. Setting the height of this blue bar-cursor to a lesser value (If it possible to do that?) should do the trick.
Why do I think that? Because the "Edit" tab needs almost the full height of the screen and when I resize it a little bit less high than the screen I can not see all the content of the tab anymore (even by scrolling).
Actually, even for the tabs with a small height (like the "Tabs" tab), the behavior is the same.
Here are the screenshots.
Additionally, hotkeys for HTML Editor are also user preferences and are available in the
about:config
. You can set them there if the GUI is unavailable for any reason.
OK. I have used that as a work-around. Actually, even if the GUI is of course more convivial, we don't play often with the customization of the shortcuts, so this way is sufficient for me.
Please check
about:config
and see whetherdom.event.contextmenu.enabled
is set tofalse
. This will block any attempt to block the context menu from showing up so a right click always shows the context menu.
dom.event.contextmenu.enabled
==true
If I have well understood, it is the right value. Isn't it?I'm not sure whether
Control+Click
is also affected by this setting. You can also test it for Control+Click issues.Could you be more explicit?
It was suspected that right-click or control-click (as equivalent to right-click) for the isolate action of DOM Erasor has context menu popup is because your browser has dom.event.contextmenu.enabled = false. Since it's not the case by your report, we'd have to find the true cause in another way.
extensions.scrapbook.key.domEraser.narrower3
was set toHyphen_Minus
. I have deleted the_
, setting it toHyphenMinus
. Now it works again (as it did in 1.13.0b7)....
Actually the key fires a search only if it is not defined as a hot-key, so it should not be a problem. As said above,
-
was not defined because the stringHyphen_Minus
was not recognized as-
.
You are right. This is the actual cause. It's a mistake we made during the coding job.
- Whether the scrollbar works in the options panel if the content overflows the dialog window.
Sorry, nothing have changed.
Could you check whether resizing the dialog window works? And whether mouse scroll has an effect?
- Resizing works.
- Mouse scroll works only when the scroll bars show up (which is not an unexpected behavior LOL).
That bad. It seems that Firefox has some special handling for Macs. We'd need further survay to fix the issue...
We close this issue since the support of command key of Mac (and also Mac style accesskey text) is already done. The issue of overflowing content in the dialog window will be investigated and discussed further in #122.
@danny0838 (Because the issue is close, I don't know if I can post here or if I have to post somewhere else. If needed, I can delete it and paste it somewhere else.)
I'm not sure whether Control+Click is also affected by this setting. You can also test it for Control+Click issues.
Could you be more explicit?
Ok, I understand now. I was already unneccessarily "translating" the Ctrl+Click
in Cmd+Click
:-D .
In DOM Eraser mode, when I use Ctrl+Click
, it works exactly the same as RightClick
, i.e. it will isolate AND make the contextual menu popping up.
It isn't the expected behavior, but, as I said before, it is not a big issue.
The newly implemented "Menu" == Alt+C
does nothing (i.e. the first shortcut defined in the "Keys" tab). Which "Menu" is it?
Actually, in "HTML Editor" mode, it writes only ©
, which is the default behavior if there is no shortcut defined.
Perhaps is it the implementation of a question I asked?:
Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut
Cmd+?
) like the one in Scrapbook X DOM Eraser mode?
@pascallothar That's fine. Discussion about hotkeys on Mac can still go here, as long as the point is not more likely about the overflowing content issue.
The menu accesskey refers to the accesskey of the main menu, just like the "F" for file, "E" for edit, and so on. On Windows the default modifier for accesskeys is Alt (Some documentation says it's Alt+Shift. But by my test only Alt works). On Mac it seems to be Control+Option or Control.
Anyway, it seems that we should not simply write "Alt" here anymore. We'd think about another way to present it.
@danny0838 , I have to correct or precise my present comment, to not give you an information that could mislead you. Here are the links that I have found:
So, it seems that definitions of words have importance, beyond their intuitive meaning. And, of course, as usual, different sources have different definitions :-(
And it seems that on your documentation research, you have mixed two somewhat different stuff.
You learn me something. I have googled to find more.
The menu accesskey refers to the accesskey of the main menu, just like the "F" for file, "E" for edit, and so on. On Windows the default modifier for accesskeys is Alt
In the first link above, we can see that Microsoft Windows gives it the name "Mnemonic" (and not "accesskey") where others talk about "Hotkey". And that, indeed, on Windows, this letter has to be «pressed together with the Alt
key».
For Mac, I have found among other stuff [http://superuser.com/questions/303525/what-is-the-shortcut-to-access-the-menubar-in-mac-os-x].
Before talking further, here is some clarification about the Function modifier key on Mac (fn
). Some settings (like brightness of the screen, sound level, multimedia, ... ) use the function keys (F1
, F2
, ... ). By default, you will, for example, access directly (without modifier) to "increase brightness" by hitting the key above the key 2
(labelled with a big sun icon, and underneath it, in small letters, "F2"). To create the event F2
, you will need to hit this same key with the modifier key fn
down (fn+F2
). But, in your system preferences, you can choose to invert this behavior, i.e. you will hit F2
to create the event F2
and fn+F2
to increase the brightness of the screen. But, if I remember well, isn't it the same on Windows and Linux?
I have just tested it and, indeed, to access the menu bar (the Apple icon on the left of the menu bar to be precise), you need to create the F2
event with Ctrl
down, i.e. to hit Ctrl+fn+F2
by default or Ctrl+F2
if you made changes in your system preferences. And after that, you can navigate to the "Scrapbook X" sub-menu with the arrow keys and Return.
But anyway, it seems that on Mac, the way to go through the menu isn't the same as on Windows and that it is not possible, if I have well understood, to implement a shortcut for the direct access to the Scrapbook X entry in the menu bar. But is it really necessary, since no other entry of the menu bar is accessed this way on Mac?
On Windows the default modifier for accesskeys is Alt (Some documentation says it's Alt+Shift. But by my test only Alt works). On Mac it seems to be Control+Option or Control.
In [https://en.wikipedia.org/wiki/Access_key], we can see that what is defined by "accesskey" is something different. "Accesskeys" are implemented in web pages themselves and have their behavior totally variable from a certain web page to an other one. And, because it has been deprecated, it is seldom used in web pages.
Looking in the code of Scrapbook X, even if I don't understand a lot, I can see that it uses code having similarities with html (javascript, CSS, xul, xml, I don't know exactly). And that some functionalities are specified using the "accesskey attribute". ([https://en.wikipedia.org/wiki/Access_key#Specifying_access_keys]).
In [https://en.wikipedia.org/wiki/Access_key#Access_in_different_browsers], in the entry about Firefox, we can see that Windows on Firefox will not use Alt
(as for "Mnemonics"), but Alt+Shift
. And that, on Mac, it used to be Ctrl
, but for the recent versions of Firefox, it is Ctrl + ⌥ Opt
.
So, FYI, I made some test on my Mac with newest Firefox.
C
alone doesn't work. Neither does Ctrl+C
, nor Ctrl+Alt(Opt)+C
, nor Alt+C
, nor Alt+Shift+C
(FYI only. I don't see it as a problem). But, as I said above, it would probably be impossible to make it work.Ctrl + ⌥ Opt + Accesskey
works and not Ctrl + Accesskey
.Ctrl + Accesskey
, but not with Ctrl + ⌥ Opt + Accesskey
. So, I suppose that Firefox, since its version 14.0.1, made the change from Ctrl + Accesskey
to Ctrl + ⌥ Opt + Accesskey
for html pages only, with the purpose to not have interactions with the accesskey attributes defined in the code of the add-ons.
Ctrl+L
will "Locate"Ctrl+S
will "Save" or focus in the "Search" barCtrl+Z
will "Undo"Ctrl+K
does NOT work (FYI only). But was this "Accesskey" not remapped to a shortcut customizable in the "Options" (for opening the Sidebar)? In the "Options", the chosen shortcut is not Ctrl+K
, so it would be no wonder that it doesn't work this way. <!ENTITY sb.note.save.accesskey "S">
, <!ENTITY sb.note.normalview.accesskey "N">
, <!ENTITY sb.note.htmlview.accesskey "H">
, <!ENTITY sb.note.tools.accesskey "O">
, <!ENTITY sb.note.fontsize.accesskey "T">
, <!ENTITY sb.note.print.accesskey "P">
, <!ENTITY sb.note.exit.accesskey "X">
do NOT work (FYI only. I would not use those accesskeys).Anyway, it seems that we should not simply write "Alt" here anymore. We'd think about another way to present it.
I agree, since it's platform dependent and even Firefox version dependent.
@danny0838 , So, my second question is:
Would it be difficult to implement some Help pop-up in Scrapbook X HTML Editor mode (I would say with shortcut Cmd+?
) like the one in Scrapbook X DOM Eraser mode?
@danny0838 , No answer: Does it mean that you didn't see my question OR that you had too much work and no time OR that it would be difficult to implement? :-)
Even to make some window (for example, saved as a file in the Scrapbook Directory to let the user fill it or edit it himself) pop up and let to the user the task to create the content of this pop-up?
@pascallothar What content you think should be written in a standalone help popup for the HTML editor?
In "DOM Eraser" mode, when you hit h
, the help pop-up shows the usage of all the "hotkeys" (not even sure anymore if it is the right word, but anyway). And when you move the mouse or if you hit a second time h
, the pop-up will disappear.
Here, in "HTML Editor" mode, one could choose a shortcut (Customizable would be better, of course; or something accessible with every keyboard layout and without conflicts with other not customizable shortcuts) that would make the usage window pop up with all the shortcuts used by "HTML Editor". And the window would disappear by moving the mouse. But also, to not use the mouse, by using the shortcut again (or and other one if not easy to implement).
What content? It depends of the implementation. It could be the same type as for "DOM Eraser". But, because the shortcuts are customizable, the pop up can not be "static" and NOT editable at the same time, because it needs to show the actual shortcuts and not the default ones.
If "static", it has to be customizable by the user, even if he has to use a not convivial way to do it (the user doesn't need to do that often, probably only once in its life) (Convivial would be a plus). This way could let more possibilities to the user. For example, for "Format with Template n
", I would "Format" the string "Format with Template" or a part of the string or even a added word (depending perhaps of the type of formatting). So I could remember easily what template match to what shortcut. Adding an icon would be a plus, but is not a necessity.
If "dynamic" (i.e. the string matching the actual shortcut would be generated dynamically) and NOT editable by the user, one could use what is already shown by the contextual menu, but put together in a single window. An other possibility would be to create a shortcut that would make the contextual menu pop up immediately with the main sub-menu shown; but is it possible?
"Dynamic" AND editable would let the user add some "custom" tips and tricks, but more important to my eyes, let add some formatted example to the entry "Format with Template n
".
But, as I said before, it depends of the type of implementation. Editable HTML or XHTML? Or something else? Because, I am not a developer, I have no clue of how to implement it exactly, only some approximative ideas.
I have read in the manual of the legacy Scrapbook [http://www.xuldev.org/scrapbook/tips.php]:
I am on Mac Os X Snow Leopard 10.6.8 on a MacBookPro, so I have no middle-click. Ctrl key behavior on Windows is usually operated by the Cmd key on Mac.
When I click on a item in the Scrapbook_X Sidebar with Cmd key down, it does the same than without the Cmd key, it opens the item in the current tab. This behaviour is not consistent with the usual behaviour on Mac and should open the item in a New Tab. And, so, I make often mistakes and open the item in a tab where I was doing some editing ... which goes lost.
Could you please implement the right behaviour for Mac or, at least, the possibility to choose it from the preferences?