On Fri, 21 Oct 2005 12:57:52 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> 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. title are there ALREADY displayed. on the window. in the titlebar. secondly - titles are an iffy thing to match by as many apps seem to like to CHANGE the title a lot thus u cant match on a property that keeps changing. > 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. e figures that out for you by telling you if it isnt unique :) otherwise its a good thing to match by. frankly - 99% of peolpe i talk to dont even knwo what a window name/class IS letalone its display MEAN anything to them. i'd rather it just worked, as opposed to have to force them to learn stuff. - but as i said - we have nothing useful to display these in as they can be arbitarily long strings and thus woudl make our dialogs arbitarily large. > 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. i'd say only in the advnaced dialog is this useful - and then i'd want an entry box as technically e can support glob matching on these fields with a tiny bit of code (so u can match "*my browser*" for example. > 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. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
