|4.4 Bug Report: Key assignment conflict
||[Apr. 9th, 2004|10:35 am]
Bug Report, version 4.4.0 (from debian/unstable): ctrl-alt-I is the keyboard equivalent for Insert/Image and HTML/Italic. (Is there a reason why the keyboard equivalents for the HTML menu are mapped to ctrl-alt instead of just ctrl?) At least on my machine, the former over-rides the latter, which is the preferred behavior in my opinion; italic tags are easier to enter by hand.|
Any chance of having a preference setting so that the cool new ctrl-L Insert/Link feature optionally includes target='_blank' in the anchor tag? Any chance of other preference settings so that the cool new ctrl-alt-I Insert/Image feature can optionally include align='right' and/or border='0' in the image tag?
Any chance of getting a preference setting so that the HTML preview, instead of opening up inside the application, saves the HTML preview to the temporary files directory and opens it with the default system browser (like the Journal/Web Links submenus)? You'd need to save two fake web pages, one with the cuts collapsed and one with the cuts expanded. And I wouldn't blame you if you chose not to emulate polls. Do-able?
2004-04-09 12:49 pm (UTC)
keyboards: if you're using emacs keybindings, using ctl+whatever makes logjam conflict with text editing.
italics vs image: intended to fix it, forgot about it. can you propose better shortcuts?
blank target: this is widely considered a bad idea; if you want a link in a new window, middle-click (ctl-click) it. i don't want to make it any easier because i hate it.
insert image: yeah, good idea.
html preview in web browser: i guess i could do it, but i'm not sure why.,. what does that add? maybe i could just fix the built-in preview?
2004-04-09 01:30 pm (UTC)
There was poll preview on the wishlist... would be easy to add once we have the poll parser on the way to an editor.
Keyboards: Why does it matter if it conflicts with emacs? You can't run them both at the same time, can you? Or is this something I don't get because on the occasions when I can't use a GUI-based text editor, I fall back on vi instead of emacs? Anyway, my preference would be to use regular ctrl-B, ctrl-I, ctrl-U for bold, italic, and underline. If you can't or won't do that, in the logjam-dev thread about the conflict somebody suggested using ctrl-alt-P (for "picture"), and I could live with that.
Blank Target: Your software, your choice. My reason for using it religiously in LJ posts (and hardly ever anywhere else) is that between slow serves and super-complicated web pages, it takes freaking near forever to redraw an LJ page, so I pop up all the external links in new windows so my readers don't have to wait several minutes when they come back to their Friends page after the link I sent them to. But now that I've learned to do it manually, I can live with it if you don't offer it. I just wish that you would.
HTML preview: Well, here's my reasoning. What's holding your existing HTML preview fork out from the Debian packages is that the guy who's responsible for building LogJam for Debian doesn't like the fact that it's dependent on gtkhtml3. You've posted good reasons in logjam-dev why you don't want to switch to gtkhtml2 the way he wants you to. So my hope was that this would be an easy alternative to implement, for those of us who can't or won't recompile it ourselves.
I pop up all the external links in new windows so my readers don't have to wait several minutes when they come back to their Friends page after the link I sent them to.
But it's the _reader's_ choice whether he wants to open it in a new window, and it's very easy for the reader to ctrl-click or middle-click. Your adding a blank target limits the reader's choices, and is therefore not to be done without compelling reason.
(thoughtful frown) This may be a programmer bias creeping in; you may be assuming that users know things that they don't. It's not my impression, as a 14-year tech support veteran, that most users know that ctrl-click or middle-click is an option. A majority know that right-click and pick "new window" off of the menu is available, but won't use it because it's too many steps.
I know I took a poll about this in my journal, and among my readers, defaulting to open external links in a new window won unanimously.
2004-04-10 04:32 am (UTC)
Why does it matter if it conflicts with emacs? You can't run them both at the same time, can you?
Here Evan means gtk2's alternative Emacs-style keybindings for editor (which can be turned on by adding gtk-key-theme-name = "Emacs" line to your ~/.gtkrc).
Also (unless there's some kind of misconfiguration on my end), images don't load properly in the HTML preview window. I only post pictures now and then, but having images show up as broken when they're really there is a little bit misleading. I imagine that this would be easy to implement, since there's already a preference for preferred browser.
I'm a big fan of user choice myself (I haven't used new window spawns or popups in my website designs for years), but to each their own. In that spirit, I'm all for adding the capability if it can be done in an elegant and unobtrusive way.