This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.

Quit When Closing Main Window

2

Comments

  • khad
    khad Social Choreographer
    Just to reiterate. The question is not whether the main application has functionality, but whether running the main application [i]windowless[/i] has functionality. It sounds like we are agreeing that it does. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



    [quote name="Examinus"]Has anybody noticed that if you close the 1Password main window whilst another window from 1P is open the app still quits? This is bad, bad behaviour. Why should the app quit when I still have a window from it open?



    I can open About 1Password, License, Check for Updates and Preferences, all of which close when I close the main window.[/quote]

    I have filed this in our internal tracker. This should not be that case regardless of what closing the [i]last[/i] window does.





    [quote name="sandbag"]Just to add my pence-worth to the argument to retain the old behaviour.



    In fact I'm not upgrading my main office Macs until you guys sort this out, as this is just going to p*** me off so much![/quote]

    That's at least a dollar's worth, there. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' /> Feel free to download version 3.5.3 from the [url="http://agile.ws/products/1Password/versions"]release history page[/url]. There are some other important fixes, though, and if this does not get reverted, I would strongly advise updating to get all the latest security fixes, etc.



    [quote name="sandbag"]I had to use my macbook to work on yesterday, and if I accidentally quit 1P once, I did it 30 times - each time having to open it and type in a 20+ character password each time!![/quote]

    I [i]know[/i] it's not a great solution (and comes with its own security implications), but consider unchecking "Disable automatic unlock for 1Password" (Preferences > Security) if you are using 1Password in your browser(s) as well. It will remain unlocked across a relaunch with that preference unchecked if it is unlocked in the browser(s). I uncheck it for convenience because I am either at my computer or closing its lid which tells it to sleep, thus locking in accordance with the "Lock when sleeping" preference. Just for what it's worth.



    [quote name="sandbag"]As long as the P1 datastore is unlocked there should be an active icon to remind us. You could put this up on the menu bar, like the keychain lock icon - or better still, oh yes, just leave the 1P icon active in the dock![/quote]

    This sounds like more of a feature request than a complaint about the recent "quit on close" change. 1Password has never done had such a notification before.



    Thank you all for continuing this conversation, though. We really appreciate the feedback. Seriously.
  • gooddy
    edited February 2011
    That new behavior is very annoying. I usually use 1PW with terminal, to log-in to ssh servers nor in browser. And I like when it's running in bg while I'm working. That's not cool type l000000ng mpassword every time.



    Do that as an option, or compile for me version without that crazy stuff, please. :3



    [size="1"]p.s. sry for my eng %)[/size]
  • Or, AWS could drastically simplify 1P Preferences to what EasyFind offers… <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/biggrin.gif' class='bbc_emoticon' alt=':D' />
  • thiswillkillthat
    edited February 2011
    I'd just like to add my two pence in favor of the old behaviour.



    One of my uses for 1Password is to aid in managing a sizable network, in which, for security reasons, I've chosen to implement a different administrator password for each computer. Keeping the 1Password window closed but readily accessible makes that task much easier. I was installing updates yesterday, and by force of habit I kept closing the 1Password window, quitting the application and locking the keychain in the process. I probably spent more time typing my password than I spent tasking computers with updates. It slowed me down so much that I've been forced to revert to the previous version.



    I know 1Password already has a lot of preferences, and I know adding one more doesn't sound like a brilliant solution, but it really makes an enormous difference to those of us that use 1Password for more than just web logins and have grown accustomed to doing things the old way.
  • khad
    khad Social Choreographer
    Welcome to the forums, gooddy. While this is being debated, consider simply not quitting 1Password. Is there functionality that running 1Password "windowless" would grant you? You do need to have the main window open in order to copy passwords. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/mellow.gif' class='bbc_emoticon' alt=':mellow:' />



    thiswillkillthat, is there a reason that simply unchecking "Disable automatic unlock for 1Password" will not work in your situation? Please do let me know. I am genuinely curious. There is still much internal debate about this and the more data points we have, the better!



    SJK FTW! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' />
  • Hi!



    At first I apologize for not having read the whole thread completely...



    I'm also one of those who want the old behavior back - at least as an option; maybe even a hidden on that is only accessible through the defaults(1) command.

    I often look up stuff in 1P and the application is/was running basically all the time on my machine.

    Still, I do see the point that 1P is not actually a document based application and thus does not need to be running when no windows are open.



    In my opinion, the actual "annoyance" with the new behavior is not that the application quits, but that one has to enter the master pwd all the time when re-opening the main window.

    (For me, all switches under "Security Options" are unchecked except "disable automatic unlock").

    I could live with the new behavior, if there was a way to skip these additional password prompts.

    Maybe 1P could leave the keychain unlocked when it quits [b]itself[/b] (i.e. when the main window is closed) and lock the keychain if the user [b]intentionally[/b] quits 1P with cmd+q.

    This way it wouldn't make much of a difference compared to the old behavior and the application could still quit when no windows are left open.



    Just my 2 cents...



    Sebastian
  • [quote name='khad' timestamp='1296791992' post='20028']

    Welcome to the forums, gooddy. While this is being debated, consider simply not quitting 1Password. Is there functionality that running 1Password "windowless" would grant you? You do need to have the main window open in order to copy passwords. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/mellow.gif' class='bbc_emoticon' alt=':mellow:' /> [/quote]



    Hello, thanx for invitation. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/happy.gif' class='bbc_emoticon' alt='^_^' />

    On my mb pro 13" I have not so much display space for keeping all apps windows opened. And It's boring type master password every time when I need 1PW.



    oh...I've just remembered about Command+H...maybe that's what I need... <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/huh.gif' class='bbc_emoticon' alt=':huh:' />
  • [Deleted User]
    edited February 2011
    [quote name='hellspawn' timestamp='1296841991' post='20053']

    In my opinion, the actual "annoyance" with the new behavior is not that the application quits, but that one has to enter the master pwd all the time when re-opening the main window.

    (For me, all switches under "Security Options" are unchecked except "disable automatic unlock").[/quote]

    Enabling that preference matters if you want to work around the annoyance of 1P being unconditionally locked when relaunching (after intended [i]and[/i] unintended quits, in my case). See a recent [url=http://forum.agile.ws/index.php?/topic/2023-security-question-with-lock-after-x-minutes-of-inactivity/page__view__findpost__p__18578]dialog I had with Rob[/url] for the gory details. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



    And with "Disable automatic unlock for 1Password" enabled it may be worthwhile to lower the "Lock after <n> minutes of inactivity" value to less than the 20 minute default. I don't want 1P to remain unlocked when idle for too long, whether or not it's running.



    I know some people want 1P to be locked when it's explicitly quit and relaunched, which is one reason why leaving "Disable automatic unlock for 1Password" enabled combined with the quit when closing main window behavior can frustrate them. But having that pref disable and a relatively low "Lock after …" value is a satisfying/secure enough combination for me regardless of what causes 1P to quit. And it seems less vulnerable than being unlocked in a windowless state.
  • khad
    khad Social Choreographer
    I do wish folks would read the thread. I know it's getting long, but, this is exactly what I said just a few posts earlier (emphasis added):



    [quote]Consider unchecking "Disable automatic unlock for 1Password" (Preferences > Security) if you are using 1Password in your browser(s) as well. [b]It will remain unlocked across a relaunch[/b] with that preference unchecked if it is unlocked in the browser(s). I uncheck it for convenience because I am either at my computer or closing its lid which tells it to sleep, thus locking in accordance with the "Lock when sleeping" preference. Just for what it's worth.[/quote]



    I am still in support of reverting the old behavior, but I think it is more the principle of the thing than the practicality of it. I never ran windowless myself. I am either using the application or I am not. Most of the time I am, since I work here <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />, so there is never any benefit to running windowless in my case. I am still curious if someone could give a good use case for running windowless. So far it just seems like most folks are complaining that they quit the app accidentally. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />



    Did anyone use 1Password windowless on a regular basis? You're not helping my case here. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' /> I'm on your side!
  • Platypus70
    Platypus70 Junior Member
    edited February 2011
    [quote name='khad' timestamp='1296890077' post='20079']

    I am still in support of reverting the old behavior, but I think it is more the principle of the thing than the practicality of it. I never ran windowless myself. I am either using the application or I am not. Most of the time I am, since I work here <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />, so there is never any benefit to running windowless in my case. I am still curious if someone could give a good use case for running windowless. So far it just seems like most folks are complaining that they quit the app accidentally. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />



    Did anyone use 1Password windowless on a regular basis? You're not helping my case here. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' /> I'm on your side!

    [/quote]



    Principle/practicality, who cares. We're not just fine-tuning some release candidate here; we're at version 3.5, and all of a sudden command-W behaves like command-Q and shuts down the whole program. So there is no way to revert back to 1PW via command-tab, which to me is both a bad princicple and bad practicality.
  • [quote name='sjk' timestamp='1296866006' post='20067']

    Enabling that preference matters if you want to work around the annoyance of 1P being unconditionally locked when relaunching (after intended [i]and[/i] unintended quits, in my case).

    [/quote]



    Automatic unlocking introduces a whole bunch of other issues for me.

    For example I like being able to login to web pages using the assigned shortcut keys.

    If my keychain is unlocked via the browser plugin and auto-unlock is disabled, there still is no easy way to access my passwords in cleartext, since accessing the keychain with the 1P app would still require entering the master password.

    With auto-unlock enabled, "anyone" with access to my machine could open 1Password and retrieve cleartext passwords and much more information.

    Also, I wouldn't be able to tell if my keychain is currently locked or unlocked -- I liked the fact that I could use "no active 1P icon in the dock" as indicator for "keychain is locked".





    [quote]

    And with "Disable automatic unlock for 1Password" enabled it may be worthwhile to lower the "Lock after <n> minutes of inactivity" value to less than the 20 minute default. I don't want 1P to remain unlocked when idle for too long, whether or not it's running.

    [/quote]



    That's just adding another layer of uncertainty for me.

    I'd like to be able to easily tell if my keychain is locked or not without trying to open it.

    Screen Saver has activated -> keychain locked

    MacBook sleeping -> keychain locked

    [b]1Password not running -> keychain locked[/b].



    and not

    1password not running + "I think I didn't unlock the keychain in my browser" + "haven't used it in a while" -> "I'm 60% sure it might be locked".





    [quote]

    I know some people want 1P to be locked when it's explicitly quit and relaunched, which is one reason why leaving "Disable automatic unlock for 1Password" enabled combined with the quit when closing main window behavior can frustrate them.

    [/quote]



    That's me.



    [quote]

    But having that pref disable and a relatively low "Lock after …" value is a satisfying/secure enough combination for me regardless of what causes 1P to quit. And it seems less vulnerable than being unlocked in a windowless state.

    [/quote]



    Sure, it would alleviate the effects of the new behavior a little.

    But I think the old behavior was perfectly good for many people.



    Also, AWS could add more useful reasons for running 1P windowless in the future.

    One suggestion from my side would be to have the password generator accessible via the right-click app-icon menu, so it could be easier used for other things than web pages.

    The go&fill menu was already mentioned...

    With the new behavior this option would be gone.



    [quote name='khad']

    I do wish folks would read the thread.

    [/quote]



    Did it now. Sorry <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



    Sebastian
  • Examinus
    Examinus Junior Member
    [quote name='Platypus70' timestamp='1296899138' post='20086']

    Principle/practicality, who cares. We're not just fine-tuning some release candidate here; we're at version 3.5, and all of a sudden command-W behaves like command-Q and shuts down the whole program. So there is no way to revert back to 1PW via command-tab, which is to me is both a bad princicple and a bad practicality.

    [/quote]



    This ^^
  • [Deleted User]
    edited February 2011
    [quote name='hellspawn' timestamp='1296904290' post='20088']

    With auto-unlock enabled, "anyone" with access to my machine could open 1Password and retrieve cleartext passwords and much more information.[/quote]

    That vulnerability can exist if 1P is running windowless.



    [quote]Also, I wouldn't be able to tell if my keychain is currently locked or unlocked -- I liked the fact that I could use "no active 1P icon in the dock" as indicator for "keychain is locked".[/quote]

    The more general issue seems to be lack of an explicit locked/unlocked indicator for every 1P context, e.g. running but not currently visible and auto-locking has/hasn't kicked in. (c.f. [url=http://forum.agile.ws/index.php?/topic/3318-quit-when-closing-main-window/page__view__findpost__p__19836]sandbag's EDIT comment[/url])



    [quote]I'd like to be able to easily tell if my keychain is locked or not without trying to open it.[/quote]

    Or having its main window in the foreground.



    And the Dock icon for its minimized main window is identical (locked appearance) when locked [i]and[/i] unlocked, which is arguably a bug. For fun, watch what happens when minimizing/unminimizing in its unlocked state while holding the Shift key. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



    [quote]1password not running + "I think I didn't unlock the keychain in my browser" + "haven't used it in a while" -> "I'm 60% sure it might be locked".[/quote]

    Same uncertainly can exist with 1P running.



    [quote]But I think the old behavior was perfectly good for many people.[/quote]

    Sure, though with a false sense of security if they thought 1P was locked while running in a windowless state.



    Even with disagreement about this "quit when closing main window" change maybe most of us agree on its value for bringing attention to [i]other[/i] worthwhile issues? <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



    Thanks for the feedback. I didn't acknowledge a few points because would-have-been-helpful context from my original post wasn't quoted in this reply. IP.Board's choices for replying/quoting could be improved. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />
  • [quote name='Platypus70' timestamp='1296899138' post='20086']

    We're not just fine-tuning some release candidate here; we're at version 3.5, and all of a sudden command-W behaves like command-Q and shuts down the whole program.[/quote]

    The change was made in 3.5.4.BETA-4 and discussed here before the final, non-beta 3.5.4 release. The reason(s) why AWS unexpectedly chose to make and retain it (for now) are still not entirely clear to me.



    [quote]So there is no way to revert back to 1PW via command-tab, which is to me is both a bad princicple and a bad practicality.[/quote]

    That's another example of why "running while windowless" behavior, in general and not only for 1P, can have a useful purpose. Still, it can be tedious managing/navigating the clutter of a large number of windowless apps (including 1P) that it would have been acceptable/preferable to quit.
  • I'll go +1 on the new functionality. The Mac software I own is split probably 50/50 on the behavior, and I much prefer closing the app. It's the more expected behavior, IMO, and leaves less security holes. Make it an option, if you like but the I much prefer the new functionality.
  • [quote name='vr8ce' timestamp='1296937817' post='20106']

    I'll go +1 on the new functionality.[/quote]

    You might have the honor of being the first person who's specifically mentioned they favor it, and definitely have the honor of it being your first post. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />
  • khad
    khad Social Choreographer
    edited February 2011
    [quote name="Platypus70"]Principle/practicality, who cares. We're not just fine-tuning some release candidate here; we're at version 3.5, and all of a sudden command-W behaves like command-Q and shuts down the whole program. So there is no way to revert back to 1PW via command-tab, which to me is both a bad princicple and bad practicality.[/quote]

    Fair enough. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



    [quote name="hellspawn"]With auto-unlock enabled, "anyone" with access to my machine could open 1Password and retrieve cleartext passwords and much more information.[/quote]

    Hold down the Shift key and select a login from the 1P toolbar button in your browser. Go ahead. I'll wait here while you do.



    ...



    When 1Password is unlocked in your browser, anyone can easily edit one of your your logins using the above method and copy and paste the password in the clear. That is why it is vital that you lock 1Password if you are not literally sitting front of your computer (or are in a secure facility to which no one else has access <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />). Please be careful.



    [quote name="hellspawn"]Also, I wouldn't be able to tell if my keychain is currently locked or unlocked -- I liked the fact that I could use "no active 1P icon in the dock" as indicator for "keychain is locked".[/quote]

    I don't think that there is any combination of security settings that would have allowed 1Password in the Dock to serve as an indicator of lock status. Maybe I am missing something here. There has been some thought given to a menu bar icon for this purpose, though...



    [quote name="hellspawn"]I'd like to be able to easily tell if my keychain is locked or not without trying to open it.[/quote]

    Wouldn't that be great! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



    [quote name="hellspawn"]Screen Saver has activated -> keychain locked

    MacBook sleeping -> keychain locked

    [b]1Password not running -> keychain locked.[/b][/quote]

    I think there might be some confusion here. If you have [b]both[/b] of the "Disable automatic unlock…" settings checked and [b]both[/b] your browser [b]and[/b] 1Password are not running, this will be the case. Otherwise, this is not a given.



    That being said, I don't think this has much to do with running windowless. This is devolving into a security settings thread. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_tongueout.png' class='bbc_emoticon' alt=':-P' />



    [quote name="hellspawn"]Also, AWS could add more useful reasons for running 1P windowless in the future.

    One suggestion from my side would be to have the password generator accessible via the right-click app-icon menu, so it could be easier used for other things than web pages.

    The go&fill menu was already mentioned...

    With the new behavior this option would be gone.[/quote]

    Now you're talking. Thanks for this information and feedback! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />
  • khad
    khad Social Choreographer
    [quote name="sjk"]That vulnerability can exist if 1P is running windowless.[/quote]

    Exactly.



    [quote name="sjk"]The more general issue seems to be lack of an explicit locked/unlocked indicator for every 1P context, e.g. running but not currently visible and auto-locking has/hasn't kicked in. (c.f. sandbag's EDIT comment)[/quote]

    You're on a roll.



    [quote name="sjk"]And the Dock icon for its minimized main window is identical (locked appearance) when locked and unlocked, which is arguably a bug. For fun, what happens when minimizing/unminimizing in its unlocked state while holding the Shift key.[/quote]

    <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' /> This is why we love you, sjk.



    [quote]Even with disagreement about this "quit when closing main window" change maybe most of us agree on its value for bringing attention to other worthwhile issues?[/quote]

    Consider that this change may be temporary and a deliberate attempt to elicit this sort of conversation from such great minds. Nothing beats a focused focus group.



    [quote]The change was made in 3.5.4.BETA-4 and discussed here before the final, non-beta 3.5.4 release. The reason(s) why AWS unexpectedly chose to make and retain it (for now) are still not entirely clear to me.[/quote]

    From what I am hearing around the water cooler, it was done in order to resolve a completely separate issue and will likely be reverted.



    Welcome to the forums, vr8ce! I hope my previous paragraph does not disappoint you. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />
  • Roger Wilco
    Roger Wilco Junior Member
    I think this is a really TERRIBLE idea. OK, you point out that there's no real standard (actually there was once since the mid '80s until Apple themselves started to break it with the iApps). You also point out that quit on close may be the way of the future since the App Store does it. But there is one HUGE difference for 1Password: if I close iPhoto or App Store and it rudely quits on me, I don't have to type my bloody password to open it again!



    I use 1Password on and off all day but I don't want it sitting on my desktop. Equally I don't want to have to keep typing my master password all day.



    You've also opened up a huge security hole in that 1Password is now left unlocked when it's not running. In previous versions, if I quit the application I would know my passwords were safe. Now if I quit it (or it quits on me) my passwords are unlocked in the browser.



    Please revert this nasty behavior (or at least give us a preference). Even Apple can admit these sort of mistakes!
  • Oh wow. I just stumbled upon this heated discussion!



    I think it really boils down to personal preference. I honestly never gave it much thought, since I'm in the habit of hitting Command-Q pretty much any time an app isn't doing work in the background and I don't plan on coming back to it within the next five minutes or so. I guess I just got in that habit when I came over from the dark side a few years back and I was used to closing programs fully.



    I think that the App Store rationale is a fairly good one, since the whole point of that software vector seems to be simplicity. But I would sure like to see it as an advanced option to change the default behaviour to quit on window close, since there are certainly some use cases for that as well. As long as we all have reasonable systems in place to ensure that our data is safe if we get sidetracked and forget to manually secure our 1Password vault, I think we're okay.



    As for me, I used to just Command-H when i wanted an app to stick around in the background, but for the most part these days I use Spaces to keep down the clutter for the few things I leave running concurrently. I'm used to doing things my own way, and this thread was a good reminder that not everyone thinks the same. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />
  • khad
    khad Social Choreographer
    Roger, nothing has changed from a security perspective. 1Password still locks and unlocks in accordance with the exact same security settings that it has always had (Preferences > Security). The only difference is that you cannot currently run 1Password windowless.







    [quote name="brenty"]I think it really boils down to personal preference. I honestly never gave it much thought, since I'm in the habit of hitting Command-Q pretty much any time an app isn't doing work in the background and I don't plan on coming back to it within the next five minutes or so. I guess I just got in that habit when I came over from the dark side a few years back and I was used to closing programs fully.[/quote]

    It really is personal preference, but expectations based on experience with other OS X apps can vary widely. I never ran it windowless myself, but still agree that quitting when closing the main window is just not very "Mac-like" regardless of how many apps Apple produces with such behavior.



    Unless we add more functionality when running windowless (or a menu bar icon), I don't see that it really makes a difference. This is mostly a religious argument at this point.



    [quote name="brenty"]…this thread was a good reminder that not everyone thinks the same. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/wink.gif' class='bbc_emoticon' alt=';)' />[/quote]

    Think different! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />
  • [quote name='khad' timestamp='1297204089' post='20260']

    This is mostly a religious argument at this point.[/quote]

    Amen! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_bigsmile.png' class='bbc_emoticon' alt=':grin:' />
  • [quote name='khad' timestamp='1297204089' post='20260']

    Unless we add more functionality when running windowless (or a menu bar icon), I don't see that it really makes a difference. This is mostly a religious argument at this point.

    [/quote]



    Then I shall begin my crusade! I love the idea (and the look) of menubar icons, but I've got so much crap up there already. I just can't take any more. To war! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/ohmy.gif' class='bbc_emoticon' alt=':o' />
  • MikeT
    MikeT Agile Samurai
    Hi guys,



    We’re reverting the change back to the way it was before the update. It’ll be available in the next update, 1Password 3.5.5. It is also available now in 1Password 3.5.5 Beta 6 if you’re using our betas.



    I hope this helps.
  • Platypus70
    Platypus70 Junior Member
    [quote name='MikeT' timestamp='1297373634' post='20374']

    Hi guys,



    We’re reverting the change back to the way it was before the update. It’ll be available in the next update, 1Password 3.5.5. It is also available now in 1Password 3.5.5 Beta 6 if you’re using our betas.



    I hope this helps.

    [/quote]



    ... and there was much rejoicing



    \o/



    Thanks.
  • Examinus
    Examinus Junior Member
    Just wanted to say thanks! I've said it before, but it's so good to have a software company that engages in discussion, listens to feedback and acts on it. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />
  • Yes, thank you very much for returning this functionality back. Hopefully, we didn't ruin the party for those who like the app closing automatically. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/rolleyes.gif' class='bbc_emoticon' alt=':rolleyes:' />
  • [quote name='Fooligan' timestamp='1297454603' post='20437']

    Hopefully, we didn't ruin the party for those who like the app closing automatically. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/rolleyes.gif' class='bbc_emoticon' alt=':rolleyes:' />[/quote]

    For at least [url=http://forum.agile.ws/index.php?/topic/3570-quit-when-main-window-closed/page__pid__20417]Bernd[/url], it appears.
  • khad
    khad Social Choreographer
    "Good morning, Pooh Bear," said Eeyore gloomily. "If it is a good morning," he said. "Which I doubt," said he.



    "Why, what's the matter?"



    "Nothing, Pooh Bear, nothing. We can't all, and some of us don't. That's all there is to it."



    "Can't all what?" said Pooh, rubbing his nose.



    "Gaiety. Song-and-dance. Here we go round the mulberry bush."
  • [quote name='sjk' timestamp='1297456744' post='20440']

    For at least [url=http://forum.agile.ws/index.php?/topic/3570-quit-when-main-window-closed/page__pid__20417]Bernd[/url], it appears.

    [/quote]



    Oh, man. Now I feel kinda sad... <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/sad.gif' class='bbc_emoticon' alt=':(' />
This discussion has been closed.