On Fri, 21 Oct 2005 11:09:39 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Oct 2005 11:08:15 +1000 David Seikel <[EMAIL PROTECTED]> > babbled: > > Now that the remember dialog is out. I will raise this again. It > > would help usability if the actual window name and class was > > printed in the dialog next to the Window name and class checkbox, > > the actual window title was printed next to the Title checkbok, and > > the same for Window type and Transience. > well heres 2 problems. > 1. we have no display widget for these yet that will handle a > scrollable display (we need to get the entry smart widgetised and all > fixed up etc.). Fair enough. > 2. i actually dont see the point. you DO know that e > will TRACK these properties and AS they change, if they do (name and > class dont, but title does, as do size and position), re-save > remember info. these are dynamic and will change. as for name and > class - i actually dont see a very good reason for this. you DO know > the code LOOKS for duplicates (ie rememebr a window but there are > more than 1 windows up with the same name and class combo) etc. and > it complains/warns you. > > if you have a good REASON for all the excess info.. let me know, but > right now we have no sane way to display it though. E knows about these things, and tracks them, but the user doesn't. It helps the user to choose between these options if the user can see what they are right now, even if they change later. As a hypothetical example - Some random email client has "srEmail - folder name" as the title for it's main window, and "Compose email" for it's compose window. While some random browser always uses "srBrowser" for all it's window titles. The user wants completely different behaviour for the email main window, email compose window, browser main window, and browser config window. Setting up appropriate advanced remember settings will be easier to figure out if that information is in the remember dialog. True, the titles are visible anyway, unless borderless or fullscreen is already turned on, but the same principal applies even more so to the match types that are not so easy to see. If you now that the window class is different because you can easily see what the window class is, then you know that window class is the right match to use. On the other hand, as you said, the code already checks duplicate classes, I still think the process will be more transparent to the user if they are shown. As you stated above, there is no infrastructure in place to support it anyway, so this discussion is moot for now. /me goes back to seeing how the new remember dialog actually works in practise.
pgpTraeSad26K.pgp
Description: PGP signature
