I'm trying to use Profont, but if I type an f followed by an i, the spacing goes crazy, ie. the letters move close together, but the cursor moves as if the spacing was normal. This happens only for f and i, and I haven't seen this in any other apps using ProFont.
Is anyone else having the same problem?
Thanks,
Andrew
Heh, it's automatically creating a ligature (single-character combination of the two letters). That definitely seems like a bug.
John
On Oct 6, 2004, at 4:24 PM, Andrew Ellis wrote:
I'm trying to use Profont, but if I type an f followed by an i, the spacing goes crazy, ie. the letters move close together, but the cursor moves as if the spacing was normal. This happens only for f and i, and I haven't seen this in any other apps using ProFont.
Is anyone else having the same problem?
Thanks,
Andrew _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On 6/10-2004, at 23:29, John Marstall wrote:
Heh, it's automatically creating a ligature (single-character combination of the two letters). That definitely seems like a bug.
John
On Oct 6, 2004, at 4:24 PM, Andrew Ellis wrote:
I'm trying to use Profont, but if I type an f followed by an i, the spacing goes crazy, ie. the letters move close together, but the cursor moves as if the spacing was normal. This happens only for f and i, and I haven't seen this in any other apps using ProFont.
Alright, there is currently a problem with ATSUI (text rendering) and ligatures... there is a version of pro-font without ligatures which will work instead until the problem is solved called ProFontIsoLatin1
Yup, that fixes it. Thanks, Sune.
John
On Oct 6, 2004, at 4:44 PM, Sune Foldager wrote:
On 6/10-2004, at 23:29, John Marstall wrote:
Heh, it's automatically creating a ligature (single-character combination of the two letters). That definitely seems like a bug.
John
On Oct 6, 2004, at 4:24 PM, Andrew Ellis wrote:
I'm trying to use Profont, but if I type an f followed by an i, the spacing goes crazy, ie. the letters move close together, but the cursor moves as if the spacing was normal. This happens only for f and i, and I haven't seen this in any other apps using ProFont.
Alright, there is currently a problem with ATSUI (text rendering) and ligatures... there is a version of pro-font without ligatures which will work instead until the problem is solved called ProFontIsoLatin1
-- Sune. "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn"
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
According to Andrew Ellis:
I'm trying to use Profont, but if I type an f followed by an i, the spacing goes crazy, ie. the letters move close together, but the cursor
I don't have this problem but using a non standard font (Bitstream Vera Mono, a very nice fixed free font), underscore have a tendency to disappear. Scrolling seems to get some back then other disappear again.
See the following screenshot, I believe it is quite easy to spot where underscore should be :)
http://www.keltia.net/download/no_underscore.pdf
Thanks for TM by the way, although I see some things missing (preferences menu for example), TM seems a blessing after struggling to find a decent editor (although jEdit comes close, it is Java).
On 6/10-2004, at 23:38, Ollivier Robert wrote:
Thanks for TM by the way, although I see some things missing (preferences menu for example), TM seems a blessing after struggling to find a decent editor (although jEdit comes close, it is Java).
That's good :-). Actually, the preferences menu is missing on purpose. At least for now the goal was to make it as easy and straight forward while also very powerful, as possible. Everything can be toggled directly in the menus, and states are saved on exit :-).
That's better, thanks
On Oct 6, 2004, at 11:45 PM, Sune Foldager wrote:
On 6/10-2004, at 23:38, Ollivier Robert wrote:
Thanks for TM by the way, although I see some things missing (preferences menu for example), TM seems a blessing after struggling to find a decent editor (although jEdit comes close, it is Java).
That's good :-). Actually, the preferences menu is missing on purpose. At least for now the goal was to make it as easy and straight forward while also very powerful, as possible. Everything can be toggled directly in the menus, and states are saved on exit :-).
-- Sune. "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn"
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On Oct 6, 2004, at 23:45, Sune Foldager wrote:
On 6/10-2004, at 23:38, Ollivier Robert wrote:
Thanks for TM by the way, although I see some things missing (preferences menu for example), TM seems a blessing after struggling to find a decent editor (although jEdit comes close, it is Java).
That's good :-). Actually, the preferences menu is missing on purpose. At least for now the goal was to make it as easy and straight forward while also very powerful, as possible. Everything can be toggled directly in the menus, and states are saved on exit :-).
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
/ Carl-Johan Kihlbom
On 6/10-2004, at 23:55, Carl-Johan Kihlbom wrote:
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
On Oct 7, 2004, at 00:04, Sune Foldager wrote:
On 6/10-2004, at 23:55, Carl-Johan Kihlbom wrote:
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
I don't agree, but I see where you're coming from. I think I'll just have to start a Preferences for TextMate petition :-D Who's with me?!
/ Carl-Johan
On 07 oct. 2004, at 00:10, Carl-Johan Kihlbom wrote:
I don't agree, but I see where you're coming from. I think I'll just have to start a Preferences for TextMate petition :-D Who's with me?!
Me. :)
If it's feasible I'd be for a solution that would allow for control both ways I'd be all for it.
And while I like the menus, if I could only have it one way, I'm afraid I'd probably go for just the pref menu. (I've gotten just TOO used to that hotkey combo ;)
Ryan
On Thu, 7 Oct 2004 00:34:00 +0200, Luc Heinrich lucsky@mac.com wrote:
On 07 oct. 2004, at 00:10, Carl-Johan Kihlbom wrote:
I don't agree, but I see where you're coming from. I think I'll just have to start a Preferences for TextMate petition :-D Who's with me?!
Me. :)
-- Luc Heinrich - lucsky@mac.com - http://www.honk-honk.com
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On 7/10-2004, at 0:41, Ryan Christensen wrote:
If it's feasible I'd be for a solution that would allow for control both ways I'd be all for it.
And while I like the menus, if I could only have it one way, I'm afraid I'd probably go for just the pref menu. (I've gotten just TOO used to that hotkey combo ;)
But then instead of pressing a single hotkey to change an option, you need to press the prefs hotkey, use the mouse to alter the option, click ok, use it.. maybe repeat again to toggle it off if it was only for a quick thing. Even if you don't remember the hotkey for the item, picking it from the menu would mostly be quicker. I think only having a prefs window will be annoying for "power" users in the long run. Doing both might work...
I would put the options a user might regularly change in the menus, and all options in the preferences. I would for example not put the display font in the menus, because that's something you set up once and be done with it.
According to Sune Foldager:
relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
You cannot change the syntax highliting colours w/o manually editing the bundle file. I'm afraid I don't think it is a good thing.
I like to have light background and to modify it, I have to find the hexcode for every colour I want to change and restart TM.
It is a bit too cumbersome.
Ollivier #63 :-)
Preference menu item please.
Sincerely,
Eric Curtis
On 7/10-2004, at 1:31, Eric Curtis wrote:
Preference menu item please. Sincerely, Eric Curtis
Good, argumentative reasons for it, please! :-).
Preference menu item please. Sincerely, Eric Curtis
Good, argumentative reasons for it, please! :-).
Well I did not want to beat a dead horse and I have to concur with the aforementioned arguments about conformity to standard mac OS X guidelines. I also agree with the fellow that mentioned the article about the little annoyances adding up.
When I first launched TM I immediately went to look for the preferences, no kidding, because that really like looking under the hood right away.
Sincerley,
Eric Curtis
On Oct 6, 2004, at 2:22 PM, Eric Curtis wrote:
Preference menu item please. Sincerely, Eric Curtis
Good, argumentative reasons for it, please! :-).
Well I did not want to beat a dead horse and I have to concur with the aforementioned arguments about conformity to standard mac OS X guidelines. I also agree with the fellow that mentioned the article about the little annoyances adding up.
When I first launched TM I immediately went to look for the preferences, no kidding, because that really like looking under the hood right away.
I concur completely
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
What would be wrong with both? In many case users will want to change a number of settings in a short time period. Having all settings in a single convenient location would suit that activity very well. Other user will want to change things as they go, so the current behavior will work for them. What's wrong with trying to support multiple usage styles?
Having preferences collected also provides the user with a greta resource and reference for what is customizable and may even expose capabilities of the application they had not yet discovered. Since the code is already written to handle the changing of settings - would it really be that difficult to whip up a nib and connect the actions?
According to Sune Foldager:
relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
You cannot change the syntax highliting colours w/o manually editing the bundle file. I'm afraid I don't think it is a good thing.
I like to have light background and to modify it, I have to find the hexcode for every colour I want to change and restart TM.
It is a bit too cumbersome.
Ollivier #63 :-)
On 7/10-2004, at 0:24, Ollivier Robert wrote:
According to Sune Foldager:
relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
You cannot change the syntax highliting colours w/o manually editing the bundle file. I'm afraid I don't think it is a good thing.
I like to have light background and to modify it, I have to find the hexcode for every colour I want to change and restart TM.
It is a bit too cumbersome.
Nobody said it was a good idea! This is version 1.0. Wait, and it will come :-). I didn't mean that syntax highlight files should be in the menus (how could that work anyway?) just the toggling of highlight on/off etc.
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
What would be wrong with both? In many case users will want to change a number of settings in a short time period. Having all settings in a single convenient location would suit that activity very well. Other user will want to change things as they go, so the current behavior will work for them. What's wrong with trying to support multiple usage styles?
Having preferences collected also provides the user with a greta resource and reference for what is customizable and may even expose capabilities of the application they had not yet discovered. Since the code is already written to handle the changing of settings - would it really be that difficult to whip up a nib and connect the actions?
I don't really like the icon, so here are some quick mockups I did using the PNG logo from the website. I made the color of the little guy brighter and more saturated, and the typewriter less saturated to take emphasis off of that. I also removed some detail from the typewriter to make the "little guy" clearer at small sizes. I think this helps.
I don't really understand though the "little guy" just kind of floating over the top of a typewriter. In my humble opinion, he needs to be interacting with something (maybe he is holding up a pencil?). Just for fun I also attached a small image of just the guy. I like the "little guy", but I'm not so sure about the typewriter. Also, I think his shoes should be red :) I'd be willing to do more work if you all want, cause I like TextMate that much :)
Dave Woodward dave@onethirtyseven.com http://www.onethirtyseven.com ........................................................ "This sentence is false."
Op 7-okt-04 om 00:04 heeft Sune Foldager het volgende geschreven:
On 6/10-2004, at 23:55, Carl-Johan Kihlbom wrote:
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
Well, I can't speak for other people, but one of the first things I wanted to do when I started TextMate, was change fore and background color of a normal text window (to white on black). The first thing I did was go to the Applications menu, to check if there was a Preferences dialog.. Now, it wasn't hard to find it in the View menu I wondered two things when doing this, would it change color for just one window, or for all windows in the applications. I also wondered if it would save state. It wasn't really a big problem, but in my personal case, a Preferences window would have been more natural/obvious. It didn't really annoy me, but it would just be smoother.
It's good that you try to minimize the number of preferences, but I would add a Preferences window, and put in any option that works on the entire application and that saves state accross application startups. (font, color,..). I mean, it's not because that you don't call it a preference, that it isn't one. Maybe keep the options in the other menu bars, but make it only work on the current window.
All the way at the bottom...!
On 07/10/2004, at 11:28 AM, Jan Sabbe wrote:
Op 7-okt-04 om 00:04 heeft Sune Foldager het volgende geschreven:
On 6/10-2004, at 23:55, Carl-Johan Kihlbom wrote:
I don't understand your argument about the Preferences. TextMate still has a lot of preferences, such as font, antialiasing, tab width, etc., but instead of keeping them all together in one place where they're easy to find they are spread out and hidden among the other menus. How is that easy and straight forward?
I don't agree that they are spread out and hidden... well, they are spread out but they arein the menus where they logically belong. For example, font setting is in the view menu, stuff that determines how the editor reacts to your input is in the behaviour menu, and stuff relating to syntax is also in the view menu etc. Putting it all in a prefs window is not much better: It takes longer time to change, and many people will check the menus first to see if it is not considered "deep" enough to end up in the prefs, I think.
Well, I can't speak for other people, but one of the first things I wanted to do when I started TextMate, was change fore and background color of a normal text window (to white on black). The first thing I did was go to the Applications menu, to check if there was a Preferences dialog..
Well, yes, the 1st thing I did was look for the preferences, but it only took a minute to realise that the settings were in the menus... for those arguing convention, there's a long history of this in pre-OS X days...
Now, it wasn't hard to find it in the View menu I wondered two things when doing this, would it change color for just one window, or for all windows in the applications. I also wondered if it would save state.
Yes, this is a very good counter argument to the premise that exposing the prefs is more usable/accessible -- I've long argued for memory (state retention) in applications, but if that's not the ruling convention, you're initially left wondering if you'll have to set the features each time... but again, it only takes opening your 2nd file to realise that's not the case...
...once learned does the lack of a preference window cause serious problems?
It wasn't really a big problem, but in my personal case, a Preferences window would have been more natural/obvious. It didn't really annoy me, but it would just be smoother.
Arguably true.
For all the apparent angst about the preferences window, I don't personally see this as a major issue, and indeed, I can appreciate the arguments for the approach taken...
In the end, I think it's a bit of a non-issue, eventually a prefs window will be the best solution for settings requiring anything more than a toggle (although I have to concur that I found the colour settings slightly dubious, in that not having a preference window seems to remove the ability to have cross-file defaults, that can be over-ridden on a per-file basis... Ah, nothing like equivocating! ; )
...I guess every new release has to have its controversial elements, al a OmniWeb's tabs! TM's been christened with its first subjective bugbear...! : )
marc
On Thu, 7 Oct 2004 12:43:06 +1100, marc wrote:
Yes, this is a very good counter argument to the premise that exposing the prefs is more usable/accessible -- I've long argued for memory (state retention) in applications, but if that's not the ruling convention, you're initially left wondering if you'll have to set the features each time... but again, it only takes opening your 2nd file to realise that's not the case.
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
Cheers, Andrew.
Maybe projects should allow per document preference overriding? Can I add this to my request for per-project variables ;-)
Ian.
On Oct 7, 2004, at 08:53, Andrew Green wrote:
On Thu, 7 Oct 2004 12:43:06 +1100, marc wrote:
Yes, this is a very good counter argument to the premise that exposing the prefs is more usable/accessible -- I've long argued for memory (state retention) in applications, but if that's not the ruling convention, you're initially left wondering if you'll have to set the features each time... but again, it only takes opening your 2nd file to realise that's not the case.
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
Cheers, Andrew. -- :: article seven Andrew Green automatic internet andrew@article7.co.uk | www.article7.co.uk _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
#ifndef __COMMON_SENSE__ | Ian Phillips #include <std_disclaimer> | http://ianp.org #endif
On Thu, 7 Oct 2004 08:53:53 +0100, Andrew Green andrew@article7.co.uk wrote:
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
and I think that is exactly the reason why people are so bothered by this, usually in mac osx applications things in the menus only apply to the current (document) window, not globally. And I'm wondering what the HIG would say about this?
Personally I don't really have that much of a problem with it, apart from the fact that i have to move past 3-5 menu items in the view menu that I've only used once to change the wrapping for example. But hey, if the developers feel this is the best thing since sliced bread, so be it. UI wise I think its a step backwards, mainly because it breaks usage patterns established by OSX. I just don't hope they keep on adding more and more menu items when the program grows in options, then TM would end up feeling like..well... windows really...
-- johan
On 7. Oct 2004, at 10:05, Johan Sörensen wrote:
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
How would moving the stuff to a preferences window make it temporary?
and I think that is exactly the reason why people are so bothered by this, usually in mac osx applications things in the menus only apply to the current (document) window, not globally.
It's been out for a day -- I think people have started it, wanted to see which preferences it offered, and then stumbled upon the missing preferences window, and ranted about it. So let's give it 14 days, and we'll see how people feels about it in that time.
And I'm wondering what the HIG would say about this?
I'm getting slapped with AHIG a lot, but no-one provides any quotes, so here are some.
Regarding preferences in general: http://developer.apple.com/documentation/MacOSX/Conceptual/ AppleSWDesign/UsingTechnologies/chapter_7_section_6.html
[...] avoid implementing all the preferences you can think of. Instead, focus your preferences on the features users might really want to modify.
A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, avoid using preferences to set those attributes. Instead, give the user modeless access to the controls for modifying that feature. For example, you might implement the feature using a menu item or a control in a palette or window.
[...]
Regarding the View menu, which I use for most options: http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGMenus/chapter_7_section_4.html#//apple_ref/doc/uid/ TP30000356/TPXREF148
The View menu provides commands that affect what users see in a window. In the Finder, for example, the View menu contains commands for displaying windows as columns, icons, or lists. Commands for showing, hiding, and customizing a toolbar belong in the View menu [...]
Personally I don't really have that much of a problem with it, apart from the fact that i have to move past 3-5 menu items in the view menu that I've only used once to change the wrapping for example.
And this is actually part of the reason why I did it as menu items. Many of the items I present in the View and Behavior menu are things I frequently change, and having them in the menu provides a key equivalent to do this (so I can work 100% from the keyboard).
So whether or not this goes against AHIG would probably depend on the frequency with which you change these items (ignoring that the View menu *is* for options relating to the view). Maybe my usage pattern differs from the average, maybe people are (without realizing it?) using preference windows as initial hints to what features a program offers (instead of going through the documentation), or maybe something third... let's put this to rest and see if it's really that unbearable!
But hey, if the developers feel this is the best thing since sliced bread, so be it.
I _do_ get the message that this bothers a lot of people, and this is of course not my goal with TextMate. But OS X also did initially bother a lot of Classic Mac users ;)
I just don't hope they keep on adding more and more menu items when the program grows in options, then TM would end up feeling like..well... windows really...
A preferences window is unavoidable in the long term, I'm not religious about it, and I wouldn't add arbitrary options to the menus!
And "keep on adding more and more", I really do not think TextMate stands out with huge unstructured menus. I'm currently in Mail.app, I see it has 17 items in its View menu, 5 of them are submenus.
But I would love to receive constructive criticism on the subject e.g. in the form of mockups.
Kind regards Allan
On Thu, 7 Oct 2004 11:05:15 +0200, Allan Odgaard allan@macromates.com wrote:
A preferences window is unavoidable in the long term, I'm not religious about it, and I wouldn't add arbitrary options to the menus!
Thats good enough for me, for a moment there I was under the impression that it was some crusade, so good to hear it's not :)
And "keep on adding more and more", I really do not think TextMate stands out with huge unstructured menus. I'm currently in Mail.app, I see it has 17 items in its View menu, 5 of them are submenus.
But I would love to receive constructive criticism on the subject e.g. in the form of mockups.
I've only made one change to to nib file, and that's moving the "Show Fonts" to "Show status bar" down to the bottom (see attached screenshot), like I said, I pretty much haven't changed them since I started using TM so I just wanted them a bit more out of the way. Works for me, I'm happy.
On Thu, 7 Oct 2004 11:05:15 +0200, Allan Odgaard wrote:
On 7. Oct 2004, at 10:05, Johan Sörensen wrote:
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
How would moving the stuff to a preferences window make it temporary?
What Johan wrote was quoted from me, so I'd like to take a stab at answering:
* The font settings you apply in the preferences window would stick. * The ones you apply using the regular menus wouldn't.
If I wanted to change a font forever, I'd adjust it in preferences. If I wanted to change it, temporarily, because of the needs of the current document, I'd change it in the menus.
This is even more pertinent outside of the realm of fonts. I might want to enable overwrite mode for the document I'm currently working on, just for the time that I'm working on it. But in general, I want to stay out of overwrite mode. Under the current system, even if I quit the program after I've made the changes to a specific document that I wanted to make in overwrite mode, I have to remember that the program has "helpfully" remembered that I made that change, and I have to switch back out of it.
I'm not suggesting that TM should remember the settings on a document-by-document basis; simply that adjustments you make using the menus shouldn't linger with you until you remember to change them again. Permanent changes are what a Preferences panel is for.
Another example (there are plenty): I'd like to be able to switch line numbering on, temporarily, and not have to turn it off again for other documents or when I quit the program.
If I change what I "syntax highlight as" in the menu, to be consistent with the current system, this should "stick" as well. If I want to syntax highlight as HTML *now*, surely I want to syntax highlight as HTML *forever*. No? Then perhaps I might want to be able to temporarily change other settings too.
Cheers, Andrew.
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
How would moving the stuff to a preferences window make it temporary?
It wouldn't, but it would change users expectations so that they no longer assumed that changes were temporary.
and I think that is exactly the reason why people are so bothered by this, usually in mac osx applications things in the menus only apply to the current (document) window, not globally.
It's been out for a day -- I think people have started it, wanted to see which preferences it offered, and then stumbled upon the missing preferences window, and ranted about it. So let's give it 14 days, and we'll see how people feels about it in that time.
Well, only counting top-level menu items there, and not counting commands, there are 80 menu items. Depending on whether you include "Enable Syntax Highlighting" there are either 20 or 21 which are really preferences. I'd say that saving 25% of the "menu real-estate" would definitely justify moving the preferences to a separate window.
An added advantage: if a future version implements per-project preference overriding, then the prefs window can be re-used as the UI for this feature.
For the record, here's what I think should be moved to preferences:
File -> Open With Encoding should be a Default Encoding preference (maybe move file encoding to the status bar)
Everything in the View menu except Fold Current Block. The fonts and color picker dialogs may also want to be left in the menu, but rely on dismissing the windows instead of having a "hide" command.
The entire Behaviour menu.
And "keep on adding more and more", I really do not think TextMate stands out with huge unstructured menus. I'm currently in Mail.app, I see it has 17 items in its View menu, 5 of them are submenus.
FWIW at least 3 of those (Hide toolbar, hide status bar, use small icons) should really be preferences according to the HIG section that you mention ;-)
Ian.
#ifndef __COMMON_SENSE__ | Ian Phillips #include <std_disclaimer> | http://ianp.org #endif
On Thu, 7 Oct 2004 10:32:22 +0100, Ian Phillips wrote:
For the record, here's what I think should be moved to preferences...
FWIW, I disagree. I think these options should be in preferences as well, with the menu options working only for the current document at the time they're invoked.
Cheers, Andrew.
Per document options seem popular! That being so, my preference (no pun intended) would be to have a hierarchy of preferences. Global (command-,) preferences, which could be overridden by per-project settings, which in turn could be overridden by per-document settings.
The advantage of having a preferences dialog is that the same UI/code could be used for all 3 of these. If people really want to have some/all of these settings available, how about either:
(a) Once AppleScript support is in they could be added to the scripts menu and bound to whichever keys the user wants. (b) A toolbar could be added and the prefs toggles can be added to it via customisation.
or some/all of them could be left in the menus as well, but this wouldn't be my preferred option.
Yours, Ian.
On Oct 7, 2004, at 11:29, Andrew Green wrote:
On Thu, 7 Oct 2004 10:32:22 +0100, Ian Phillips wrote:
For the record, here's what I think should be moved to preferences...
FWIW, I disagree. I think these options should be in preferences as well, with the menu options working only for the current document at the time they're invoked.
Cheers, Andrew. -- :: article seven Andrew Green automatic internet andrew@article7.co.uk | www.article7.co.uk _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
#ifndef __COMMON_SENSE__ | Ian Phillips #include <std_disclaimer> | http://ianp.org #endif
On Thu, 7 Oct 2004 13:30:30 +0100, Ian Phillips wrote:
Per document options seem popular! That being so, my preference (no pun intended) would be to have a hierarchy of preferences. Global (command-,) preferences, which could be overridden by per-project settings, which in turn could be overridden by per-document settings.
I hadn't really considered per-project settings, although I suppose it seems sensible. I'm anxious, though, not to be misunderstood about what you call "per-document settings". I really, emphatically believe that if you change a setting using the menus, it should act in a completely temporary way.
That is to say: if your global preferences state that you don't normally want overwrite mode to be on, but you switch it on using the menu while editing a given document, it shouldn't magically spring back on when you next load that document. The menus are for the here-and-now.
Seriously, the menus give no indication whatever of what's going to be remembered and what isn't. If my overwrite settings get applied across all documents and are remembered until I notice that I need to switch them back, why doesn't the syntax colouring option do the same?
Cheers, Andrew.
On Oct 7, 2004, at 6:56 AM, Andrew Green wrote:
I hadn't really considered per-project settings, although I suppose it seems sensible. I'm anxious, though, not to be misunderstood about what you call "per-document settings". I really, emphatically believe that if you change a setting using the menus, it should act in a completely temporary way.
And I personally like to see per-language settings.
Tab stops for CSS I like to put at 20 characters, Ruby 2 characters with tabs-to-spaces turned on (silly community) , and all other languages 3 characters with real tabs.
Does TextMate 'learn' your preferences on a per-language basis?
On Thu, 7 Oct 2004 07:02:54 -0600, Gavin Kistner wrote:
And I personally like to see per-language settings.
I don't think out positions are all that different -- it may well be sensible for the preferences to be organised in this way.
I'm simply arguing that if I generally prefer 3-space tabs, but open a document and use the menus to set 8-space tabs, I don't want the program to assume that I've changed my preference for all documents thereafter. Whether my preference is expressed truly globally, or on the basis of per-language definitions is really another issue.
Cheers, Andrew.
[The following is not refering to the current version of TM; it's just a general discussion.]
To break it down, you could say that there are four levels on which to change settings: 1. Globally. 2. Per language. 3. Per project. 4. Per file or document.
...and two modes: A. Permanent changes. B. Temporary changes.
The_most flexible_ system would then be the ability to change on all levels, in both modes. In pratice, this is probably not desirable as it would bloat the interface almost no matter how it is done. I do agree (but this is not necessarily the view of the TM author) that more things should be changable on level 2 for instance, while I have less use for levels 3 and 4 (but this is also a matter of taste). I think in the future, some thought needs to go into this in this with respect to future TM development. It's always a balance of keeping it simple/non-bloated but also giving you the possibilities you want.
Like Allan mentioned, I think in the long run a preferences system of some kind (and maybe integrated with an editor for language stuff/syntax highlight) is unavoidable. But that said, I really like the ability to quickly change behaviour settings around like now :-).
[The following is not refering to the current version of TM; it's just a general discussion.]
To break it down, you could say that there are four levels on which to change settings:
- Globally.
- Per language.
- Per project.
- Per file or document.
...and two modes: A. Permanent changes. B. Temporary changes.
The_most flexible_ system would then be the ability to change on all levels, in both modes. In pratice, this is probably not desirable as it would bloat the interface almost no matter how it is done.
While it is possible to describe the universe of preference possibilities in this way, I think what's being advocated (at least by Andrew, and myself) is much more simple:
1. Global, permanent. This amounts to being a default language, like #2 next.
2. Per language, permanent. A "default" language could take the place of #1, previous.
3. Per *window*, temporary. These are changes from the permanent settings that affect a document, which you might enable via the menus, and which last only until you close the window. Opening the same document again will revert to the permanent, per-language settings.
I can certainly see the value in a per project settings scope, too, but I'd suggest it makes sense to see 1-3 above implemented first, since that would likely cover 80% of what people seem to be advocating here.
And, it's also simpler to do 1-3 (really, 2-3 with a default language), because they don't involve saving settings per document; all permanent settings are for the application, even though there are different settings sets that apply to different documents.
Michael
On 7/10-2004, at 20:44, Michael A. Alderete wrote:
While it is possible to describe the universe of preference possibilities in this way, I think what's being advocated (at least by Andrew, and myself) is much more simple:
Alright... just to clarify: I didn't mean that all those posibilities had to or should be realised, just listing them all so we have something to compare our arguments against :-).
On 7. Oct 2004, at 14:56, Andrew Green wrote:
This mail only to clarify! No need to reply!
Seriously, the menus give no indication whatever of what's going to be remembered and what isn't. If my overwrite settings get applied across all documents
The changes only affect the current and new documents.
and are remembered until I notice that I need to switch them back, why doesn't the syntax colouring option do the same?
The difference with syntax coloring is that it remembers per file extension.
So if you load a .h file and change "Syntax Highlight as" from e.g. C++ to ObjectiveC, all future .h files will be colored like that.
Part of me would like all settings to work like that, part of me thinks it'll be perceived as very non-deterministic (and IMHO only really useful for soft wrap).
Kind regards Allan
Sune Foldager wrote:
That's good :-). Actually, the preferences menu is missing on purpose.
Can I place a vote for following Mac OS UI convention where possible?
I fully applaud the philosophy behind no prefs window, but as a user I spent my first few minutes using TextMate frustratedly hunting for the prefs.
App menu > Preferences is a convention that 99% of users will be familiar with. 99% is a lot of people to annoy, no matter how good your underlying philosophy.
(imho!)
drew.
On 7/10-2004, at 0:50, Drew McLellan wrote:
Sune Foldager wrote:
That's good :-). Actually, the preferences menu is missing on purpose.
Can I place a vote for following Mac OS UI convention where possible? I fully applaud the philosophy behind no prefs window, but as a user I spent my first few minutes using TextMate frustratedly hunting for the prefs.
Why? Did you need to change some setting you couldn't find anywhere? Why is looking through the relevant menu (view for view-related, behavior for most edit-related etc.) so big a problem? I don't see that it is. IMHO of course.
App menu > Preferences is a convention that 99% of users will be familiar with. 99% is a lot of people to annoy, no matter how good your underlying philosophy.
So you think that people will actually be _annoyed_ by this?... I should hope it takes more to annoy people... the advantage of this is that there are hot keys for most things that you then can change quickly, without venturing into a prefs window.
Sune Foldager wrote:
Can I place a vote for following Mac OS UI convention where possible? I fully applaud the philosophy behind no prefs window, but as a user I spent my first few minutes using TextMate frustratedly hunting for the prefs.
Why? Did you need to change some setting you couldn't find anywhere? Why is looking through the relevant menu (view for view-related, behavior for most edit-related etc.) so big a problem? I don't see that it is. IMHO of course.
I needed to change a setting. App menu > Preferences was the *first* place I looked, because the convention is that that's where settings are kept. I didn't look through the menus - why would I? That's not where you set preferences.
App menu > Preferences is a convention that 99% of users will be familiar with. 99% is a lot of people to annoy, no matter how good your underlying philosophy.
So you think that people will actually be _annoyed_ by this?... I should hope it takes more to annoy people... the advantage of this is that there are hot keys for most things that you then can change quickly, without venturing into a prefs window.
Yes, it annoyed me. It doesn't take much to knock a user off his stride.
It's a longish read, but a valuable one: http://www.joelonsoftware.com/uibook/fog0000000249.html
An important extract:
"So that's what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up. Even something which seems like a tiny, inconsequential frustration affects your mood. Your emotions don't seem to care about the magnitude of the event, only the quality."
drew.
On 7/10-2004, at 1:32, Drew McLellan wrote:
I needed to change a setting. App menu > Preferences was the *first* place I looked, because the convention is that that's where settings are kept. I didn't look through the menus - why would I? That's not where you set preferences.
What is preferences? Is overwrite mode? Is column-mode for selection? I think some people here are taking a much too traditional approach to it. Right now, I don't see any reason for having that window, except to make things slower. You only make the mistake of looking for the prefs window ONCE. You can now quicker change settings with hotkeys etc. MANY times in the future.
Yes, it annoyed me. It doesn't take much to knock a user off his stride.
I'm sorry to hear that.
On Thu, 7 Oct 2004 01:35:01 +0200, Sune Foldager wrote:
You can now quicker change settings with hotkeys etc. MANY times in the future.
But under the current system, you have to go and change them back again any time you want them to be temporary.
Cheers, Andrew.
On Thu, 7 Oct 2004 00:10:17 +0200, Carl-Johan Kihlbom extra@newcode.se wrote:
I don't agree, but I see where you're coming from. I think I'll just have to start a Preferences for TextMate petition :-D Who's with me?!
Me and Apple Computer, Inc., for starters.
On Thu, 7 Oct 2004 01:35:01 +0200, Sune Foldager cryo@diku.dk wrote:
Yes, it annoyed me. It doesn't take much to knock a user off his stride.
I'm sorry to hear that.
I'm discouraged by this thread, I hope TextMate won't be another product whose developers think they know better than Apple's UI team AND negatively-surprised users.
Like, say, BBEdit.
:-(
Please, guys, don't make us argue the carefully-considered conventions of Mac software to you; we're potential customers who need software that fits us. You've created something that fits your needs and aesthetics, which is a great start. Now adapt it to suit your target audience (all of whom are Mac users, by the by) without ruining it for yourselves, and the world will have another piece of great software instead of another mediocre wanna-be.
If you don't understand folks' objections to abandoning conventions from the Apple HIG, please explain why your way is an *improvement* -- right now all we know is that it's different, and that's apparently not enough for some of us who understand the separation of document state and application state that the Preferences window makes explicit. What problem does this deviance from user expectations solve?
Thanks for your great work so far.
On 7/10-2004, at 17:56, Ryan Platte wrote:
I'm discouraged by this thread, I hope TextMate won't be another product whose developers think they know better than Apple's UI team AND negatively-surprised users.
Yes well... read these quotes from Allan, earlier in this thread:
I'm getting slapped with AHIG a lot, but no-one provides any quotes, so here are some.
Regarding preferences in general: http://developer.apple.com/documentation/MacOSX/Conceptual/ AppleSWDesign/UsingTechnologies/chapter_7_section_6.html
[...] avoid implementing all the preferences you can think of. Instead, focus your preferences on the features users might really want to modify.
A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, avoid using preferences to set those attributes. Instead, give the user modeless access to the controls for modifying that feature. For example, you might implement the feature using a menu item or a control in a palette or window.
[...]
Regarding the View menu, which I use for most options: http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGMenus/chapter_7_section_4.html#//apple_ref/doc/uid/ TP30000356/TPXREF148
The View menu provides commands that affect what users see in a window. In the Finder, for example, the View menu contains commands for displaying windows as columns, icons, or lists. Commands for showing, hiding, and customizing a toolbar belong in the View menu [...]
<<<
Maybe YOU people should start comming up with some argumentative quotes and references from the AHIG :-).
Please, guys, don't make us argue the carefully-considered conventions of Mac software to you; we're potential customers who need software that fits us. You've created something that fits your needs and aesthetics, which is a great start. Now adapt it to suit your target audience (all of whom are Mac users, by the by) without ruining it for yourselves, and the world will have another piece of great software instead of another mediocre wanna-be.
Believe it or not, a _lot_ of people like the preferences the way they are now.. I don't think you speak for the entire target audience, while I do acknowledge that several people on this list have complained about the lack of a prefs window.
If you don't understand folks' objections to abandoning conventions from the Apple HIG, please explain why your way is an *improvement* -- [...]
I believe Allans post and also previous posts from him and me explain our argument well.
What problem does this deviance from user expectations solve?
Deviance from _some_ users expectations. What it solves or rather why it has been chosen is explained elsewhere, in Allans earlier post etc.
Thanks for your great work so far.
Just a note: I am not speaking for Allan here, and I am not on the payroll for Macromates. I am 'just' a friend of Allan.
On Thu, 7 Oct 2004 18:09:30 +0200, Sune Foldager wrote:
The View menu provides commands that affect what users see in a window.
That's fine. The problem is that those commands also affect what users see in every new window created thereafter.
Cheers, Andrew.
Hi Sune,
On Thu, 7 Oct 2004 18:09:30 +0200, Sune Foldager cryo@diku.dk wrote:
On 7/10-2004, at 17:56, Ryan Platte wrote:
I'm discouraged by this thread, I hope TextMate won't be another product whose developers think they know better than Apple's UI team AND negatively-surprised users.
Yes well... read these quotes from Allan, earlier in this thread:
I apologize; I leaned too heavily on Gmail's threading, which put Allan's comments in another "conversation", since the subject line changed. I should have caught up before posting.
But it does bother me when developers respond to user comments & criticism in an opposing way, rather than facilitating a valuable discussion that can improve and/or focus the product. If somebody's so passionate about a product as to write about it, they may be annoying, but they represent a potential fan base, and at least free market research, both of which are like gold if the goal is widespread adoption.
A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, avoid using preferences to set those attributes.
As has been discussed, several of the menu items are "personal preference" choices rather than "temporary setting" choices, hence do have a place in a Preferences window.
Maybe YOU people should start comming up with some argumentative quotes and references from the AHIG :-).
Touche.
I'll work from: http://developer.apple.com/documentation/MacOSX/Conceptual/AppleSWDesign/Usi...
My comments are prefaced with dashes.
"Preference settings are user-defined parameters that your software remembers from session to session. Preferences can be a way for your application to offer choices to users about how the application runs. Preferences often affect the behavior of the application or the default appearance of content created with the application.
"To reduce the complexity of your application, be picky about which features should have preferences and which should not. The key is to implement preferences only for those features that your users are likely to find useful. In other words, avoid implementing all the preferences you can think of. Instead, focus your preferences on the features users might really want to modify."
-- I read the above paragraphs to mean that prefs are expected to be the main mechanism for persistent changes. This isn't explicit, but since the Preferences item is a standard element of Aqua, I hope you'll allow that it's reasonable to understand this as an explanation of which things should go there. Note that up to this point the discussion of what to include in the prefs is what complexity to expose to the user, not where to put complexity.
"A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, avoid using preferences to set those attributes. Instead, give the user modeless access to the controls for modifying that feature. For example, you might implement the feature using a menu item or a control in a palette or window."
-- And (according to my reading and understanding) here's the criterion for whether something should be a pref vs. attribute modified through another UI element: how often does it change? To me, the distinction is clear, if poorly elucidated: prefs are persistent; state changes through other UI elements are temporary.
Now adapt it to suit your target audience (all of whom are Mac users, by the by) without ruining it for yourselves...
Believe it or not, a _lot_ of people like the preferences the way they are now.. I don't think you speak for the entire target audience, while I do acknowledge that several people on this list have complained about the lack of a prefs window.
Of course there are those who like the current design -- after all, the developers chose to do it a way they liked. My mention that all are Mac users was intended to point to the fact that no-one would be surprised at a Preferences window, while many will be surprised and confused on various occasions at its absence.
What problem does this deviance from user expectations solve?
Deviance from _some_ users expectations. What it solves or rather why it has been chosen is explained elsewhere, in Allans earlier post etc.
OK, deviance from Aqua. And no, I don't think there's been an explanation of what problem it solves, although I've certainly been wrong before, in fact, just a few minutes ago, I recall. ;-) Why it was chosen, I understand. I'm asking a different question.
On Thu, 7 Oct 2004 01:18:39 +0200, Sune Foldager wrote:
So you think that people will actually be _annoyed_ by this?
Yes; there's plenty of evidence of that on this list, and in the (excessive, IMHO) hostility expressed on the web.
Cheers, Andrew.
-
Allan Odgaard -
Andrew Ellis -
Andrew Green -
Arnaud Mamias -
Carl-Johan Kihlbom -
David Woodward -
Drew McLellan -
Eric Curtis -
Gavin Kistner -
Ian Phillips -
Jan Sabbe -
Jeff Ganyard -
Johan Sörensen -
John Marstall -
Joost Schuttelaar -
Luc Heinrich -
marc -
Michael A. Alderete -
Ollivier Robert -
Ollivier Robert -
Ryan Christensen -
Ryan Platte -
Sune Foldager -
timothy martens