Jump to content

iAnnoyance Winner: "Stoplight"

Swad

By Swad,
in Front Page News and Rumors

 Share
53 posts in this topic

Recommended Posts

Swad
Swad
Posted
Posted

Ladies and Gentlemen, we have a winner!

 

Andy Matuschak and his pal Joe Osborn (both of Pixen fame) have submitted the winning entry for our first iAnnoyance Challenge with an app they're calling Stoplight. (Which is a great name - we'll stick with it. :))

 

Stoplight is a SIMBL plug-in that works via a Preference Pane. It allows you to change the windowing behavior for any and all Cocoa based apps (Carbon apps don't work at the moment, but hey, that's why this is open source...).

 

Here's how to install it:

 

1. Download and install SIMBL from http://culater.net/software/SIMBL/SIMBL.php (Make sure you're running the latest version, 0.8.1)

2. Drag StoplightHack.bundle into ~/Library/Application Support/SIMBL/Plugins/

3. Double-click Stoplight.prefPane.

4. Configure as you like on a per-application basis, or exclude certain apps.

 

After you change an application's attributes, restart the app for it to take effect.

 

Go ahead and test it out and let us know what you think!

 

Download the latest version here!

Link to comment
Share on other sites
joe.osborn
joe.osborn
Posted
Posted

Thanks for running the contest! Even though I kind of like the default behaviors, I think it's valuable to re-examine assumptions like those from time to time, and 'mechanisms'(or, as I like to say, 'hacks') like these are excellent for that purpose.

 

So, thanks again. Andy and I will be glad to give the next iAnnoyance a shot, too. (:

 

I'd also like to thank JonZ14 of this forum for our icon and Ian Henderson( http://ianhenderson.org ), another of the Pixen coders, for some of the framework code we used in writing our SIMBL hack. Thanks!

Link to comment
Share on other sites
SaberSHO
SaberSHO
Posted
Posted

Awesome!

 

I had just about finished my SIMBL plugin that accomplished the tasks, but had not yet even started on the pref pane. It took a while of spinning my wheels to realize that SIMBL was the way to go. I think im gonna continue work on my own version, if only because i have at least a bit of time invested in it already. Congrats to the winners...i guess ill just have to work faster next time...

Link to comment
Share on other sites
SaberSHO
SaberSHO
Posted
Posted

wow...upon looking through the soure code, i can see that i was definatly on the right track with my own attempt. I also had started with the megazoomer plugin and was using its method swizzling to get the close behavior working. I was having a lot more trouble with the zoom though. It boosts my confidence that I can hopefully help the community in the next challenge.

 

Speaking of the next challenge, how about next weekend Mash? :D i wont have such st00pid distractions as work and the girlfriend next weekend (okay, the GF isnt st00pid, but still very much a distraction)

 

oh well, i guess ill go to sleep now....damn...those 3 red bulls i bought earlier are gonna go to waste! or maybe ill take the time to work on CPUThrottler

Link to comment
Share on other sites
John the Geek
John the Geek
Posted
Posted

I agree with them. I have absolutely no use for this, as my windows behave exactly as they are supposed to. When I close a BBEdit window the app stays open because I'm likely about to open another one. I hate that GarageBand was quiting just because I closed one window to go open another one, but thankfully now I get a popup window asking if I want to open another window or quit. Quitting without my consent was the annoyance.

 

I don't use Maximize much. I just resize on the fly.

Link to comment
Share on other sites
Muriac
Muriac
Posted
Posted

It's not worth reading the whole Ars Technica comment thread, but I'd like to point out that they're arguing with themselves more than with the competition.

 

Also, as the most vocal detractor of this program in the original thread, I'd just like to say that I'm impressed at how quickly it got done, and I'm downloading it now to check it out. Congratulations, Andy and Joe. And nice icon, jonz14.

 

Edit: and it's pretty awesome. I'm not using it on close buttons for reasons I mentioned in the other thread, but this zoom functionality is wicked. Two issues, though:

 

1. The zoom button doesn't quite zoom full-screen on my MacBook. It gets everything except a few pixels on the left. Is this on purpose?

 

2. I was happy to see that pushing the zoom button again returns the window to its original size. However, it puts it in the middle of the screen even if that was not its original location.

 

Again, good job.

Link to comment
Share on other sites
moksha
moksha
Posted
Posted

Excellent work on this! I forgot to add Preview to my list of apps that should quit when all windows are closed but don't, but now that's solved. For some reason, Activity Monitor doesn't quit when I configure it to, but this is still great!

Link to comment
Share on other sites
A Nonny Moose
A Nonny Moose
Posted
Posted

Well, we have our "Dingbat of the Week" award from ars also:

 

$500? Anyone with enough talent to do this will feel like there are far more lucrative ways to fill their time.

 

Like release it themselves and charge for it.

 

I take it they don't know how hard it is to make $500 marketing a piece of shareware.

 

and here's the quote needed for version 2:

 

How about someone fix only being able to resize a window on one corner.
Link to comment
Share on other sites
R. Patrick Cameron
R. Patrick Cameron
Posted
Posted

I do have to say that I thought long and hard about my response to this contest and the application. I find myself split between the two battling camps. Those are:

  1. Those who find the entire idea of the “iAnnoyance” competition wrong and pointlessl; and,
  2. Those who agree with every aspect of this competition.

Personally, I am somewhere in between. I think it’s a great idea to offer a bounty to address aspects of the OS that really ought to have been addressed already. (I can already hear everyone shouting to FTFF, for instance.) But I have a few points I’d like to make.

Regarding “Stoplight”: I feel the “Red means ‘Stop’, Green means ‘Go’” challenge to be unnecessary. As has been pointed out, this challenge has been commented on over at Ars Technica, and most of the comments aren’t particularly nice. Unfortunately, I must say I agree with most of the comments and posters at Ars, and here’s why:

  1. The nature of the Close button of OS X windows is supposed to be different based upon the type of application. For document–based applications, the Close button is supposed to close the window, but leave the application running; this is to be the case even when the last window of a running application is closed. Likewise, for single–window applications, closing the window should quit the application, unless it continues to process information and run in the background (i.e., iTunes or Transmission).
    Closing Windows
     
    Users can close windows by:
    • Choosing Close from the File menu
    • Pressing Command-W
    • Clicking the close button

    When a user closes a document window, your application should:

    In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window.

    [*]A utility to allow the user to modify standard OS behaviors may be useful in some situations, but to modify behaviors that are abiding by the established HIG of an OS should not be seen as something justifying an entry into this competition. The target of this should have been to address those applications which do not conform to Apple’s HIG. (A particular example would be Apple’s own Address Book application: It barely meets their own require for brushed metal windows, but is also a single–window application. Once the application window is closed, the application continues to run in the background—this is contrary to the HIG for single–window applications.) By modifying the action of the Close button of both document–based applications and single–window applications, this particular “iAnnoyance” is contrary to Apple’s HIG, and creates an even more confusing computing environment.

    To address the green Zoom button of the window, I feel that this contest has inappropriately branded it as a maximize button, when this is not the case. Again, the HIG are quite explicit as to the nature of the Zoom button:

    Resizing and Zooming Windows

     

    Your application determines the minimum and maximum window size. Base these sizes on the resolution of the display and on the constraints of your interface. For document windows, try to show as much of the content as possible, or a reasonable unit, such as a page.

     

    Your application also sets the values for the initial size and position of a window, called the standard state. Don’t assume that the standard state should be as large as possible; some monitors are much larger than the useful size for a window. Choose a standard state that is best suited for working on the type of document your application creates and that shows as much of the document’s contents as possible.

     

    The user can’t change the standard size and location of a window, but your application can change the standard state when appropriate. For example, a word processor might define the standard size and location as wide enough to display a document whose width is specified in the Page Setup dialog.

     

    The user changes a window’s size by dragging the size control (in the lower-right corner). As a user drags, the amount of visible content in the window changes. The upper-left corner of the window remains in the same place. The actual window contents are displayed at all times.

     

    If the user changes a window’s size or location by at least 7 pixels, the new size and location is the user state. The user can toggle between the standard state and the user state by clicking the zoom button. When the user clicks the zoom button of a window in the user state, your application should first determine the appropriate size of the standard state. Move the window as little as possible to make it the standard size, and keep the entire window on the screen. The zoom button should not cause the window to fill the entire screen unless that was the last state the user set.

     

    When a user with more than one monitor zooms a window, the standard state should be on the monitor containing the largest portion of the window, not necessarily the monitor with the menu bar. This means that if the user moves a window between monitors, the window’s position in the standard state could be on different monitors at different times. The standard state for any window must always be fully contained on a single monitor.

     

    When zooming a window, make sure it doesn’t overlap with the Dock. For more information about the Dock, see “The Dock”.

    Source:

    Op. cit.

    As you can see, the Zoom button is not intended to maximize the window, but rather switch between the application’s predetermined ‘standard state’ and the modified ‘user state’. Many applications do not adhere to this standard (such as the aforementioned iTunes), but individual applications’ inability to follow established standards should not be seen as a problem with the OS itself. If we want consistency, we need to ask the developers of these applications to follow the HIG, and not create our own hacks for filling in the gaps. Most developers accept feedback, and when an application’s behavior is contrary to established guidelines it ought to be viewed as a bug, unless explicitly deemed appropriate to act contrary.

     

    The other part of my gripe comes from the way in which Stoplight works. Stoplight is a ‘plug–in’ for SIMBL, which acts as an input manager. I believe John Gruber (of Daring Fireball fame) put it best when he said:

    The supported purpose for input managers is to allow developers to define new ways for users to enter text. However, the code in an input manager can pretty much do what it wants to inside an application’s address space, and so thus, input managers have turned into an unofficial channel for hacking system and application behavior. E.g., most of the hacks euphemistically described as “plug-ins” on Jon Hicks’s Pimp My Safari web site — such as Saft and PithHelmet — are input manager hacks. “Plug-ins” implies the use of a legitimate API intended for extending or modifying an application; Safari, unfortunately, has no plug-in API, so any developer wishing to extend or modify Safari must resort to unsupported mechanisms such as input managers.

     

    As stated before, every installed input manager loads into (nearly) every application. Input managers that are targeting one specific application, such as the way Saft and PithHelmet patch Safari or the way Smart Crash Reports patches Crash Reporter, typically perform some identifier checking so as only to deliver their actual payload inside the application they’re targeting. But, no bones about it, the nature of input managers is such that they’re loaded into every app on your system. …

    Although Gruber was referring to Unsanity’s Smart Crash Reporter, the same holds true for any hack that uses an Input Manager interface—in this case, SIMBL. Loading this hack into the system, and making the address space of every running application available to Stoplight is, I believe, foolish and an unsafe practice. Having the source code to Stoplight available will hopefully ensure that it does not become an unstable application or otherwise affect the system in unintended ways, but it does not guarantee it.

     

    I know this was a bit long, however I feel that these points need to be addressed, and people made aware. If one is going to offer a bounty for fixing perceived problems with the OS, let’s first ensure that there really is a problem to be fixed. In this case, modifying the Close and Zoom behavior of windows is not something that needs to be addressed on a system–wide level, but rather on an application–based level. And even then, they should be filed as a bug with the developer and not attempted to be remedied with third–party, ill–conceived hacks.

     

    (Normally I would not have even commented, but I felt that this was a topic that ought to be addressed, especially considering the amount of attention that it has garnered. Everyone has their own opinion—and is rightfully entitled to it—and I am in no way attempting to tell people their opinions are wrong. However, I am making it known that I do not believe that this perceived “iAnnoyance” is something that needs to be addressed, and the manner in which is was addressed could have been better handled as well. Perhaps future entrants in this competition will be a better fit; I just feel that as the inaugural entry, “Red means ‘Stop’, Green means ‘Go’” was ill–thought out.)

Link to comment
Share on other sites
jrrjrr
jrrjrr
Posted
Posted

My machine is my machine, and no one else's, and I want to use it and have it work just the way that I like. I don't want to have to be a slave to any "official" guidline. This little competition and the resulting application give me options for configuring my machine to my tastes. This is a good thing, and it does no harm to anyone else.

Link to comment
Share on other sites
lemniscate
lemniscate
Posted
Posted

To be fair, there's no way to make Stoplight work (at least, as far as I know) without injecting code into every process.

 

But besides that, I think Patrick's right on every point. As Joe and I were making Stoplight, we were talking through how to fix the zoom behavior: "So... right now, how does zoom work?" "It sizes to content, which is the right behavior, really: no wasted space." "So what are we doing?" "We're making it use the wrong behavior: fill the screen regardless of wasted space." But if it's what you want, I guess there's really no reason to let arguments on usability stop you because it's just how you want it to behave.

 

I do kind of think there's some merit to the "hide if last window" functionality simply because it's inconsistent and startling sometimes when closing the last window closes the app (like in iCal, etc)... but I wouldn't use it myself.

 

Edit: Also, Joe's coming back over a bit later today; we're going to squash some bugs and maybe make an installer.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...