<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 25, 2014 at 2:47 AM, Thomas Pfeiffer <span dir="ltr"><<a href="mailto:colomar@autistici.org" target="_blank">colomar@autistici.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br></div>
For file managers, putting the search in the Places panel works for simple search (though I'd put it at the top, because the list of places can get longer than the container's height and you'd have to scroll to get to the search) but what about all the search options that e.g. Dolphin offers? That wouldn't fit in the panel...<br>

</blockquote><div> </div><div>This is relatively easily addressed by a collapsible Options section under Search that is exposed, or made available to be exposed, when search is active. In practice, I've found this works quite well.<br>

</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Plus, we have to keep in mind that the places panel in Dolphin is optional, so users might not even have it visible but still want to search.<br></blockquote><div> </div><div>Fair point. For clarity though, this is proposed as a design pattern that might be helpful when category/content selection is already available in your interface design. I (already) fully acknowledge that there will be times when that is not applicable. And even if it is applicable, I fully acknowledge that it simply may not fit with the desired visual design for the application. That's fine too I think.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Actually, the "search" in media players is a filter, not a search. If we say that a filter should always be placed on top of the thing it filters, that would work for media players (Amarok already does it that way, too) and file managers as well.</blockquote>

<div><br></div><div>Filters filter already presented content. The pattern works for Amarok's library because Amarok presents in its entire library in a tree view. Not all media players do this. In fact very few do. Most have a category/content selection in a separate pane that is not restricted to just categories of the music library (e.g. playlists, radio stations, etc.). The filter pattern is certainly a good solution for Amarok's music library given the way it is presented.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I agree, though, as mentioned before, this only works for a simple search with no options. If we have options, they could only be put in a popup called from a button in the search field.</blockquote>

<div><br></div><div>As mentioned above, collapsible options exposed when search is active is another way to address advanced search. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="">The thing is: Our general approach is to use the HIG to try to standardize on what's already there (take the best approach we currently see and make that the standard across all KDE software) instead of coming up with completely new things.<br>

</div>
The reason behind that is a practical one: If we standardize on something that is already implemented in many applications, chances are that other applications currently doing it differently may switch to it for the sake of consistency. If we introduce something completely new, the risk is high that no application will implement it, and an HIG that isn't implemented anywhere doesn't have a high chance of being respected in future applications.<br>

<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>That's fine by me. I do think though that that approach rather compels UI designers to abandon the guidelines when a potentially better approach is discovered. It also means it's more likely that new/better approaches will inevitably be discovered outside of the KDE community, used by UI designers in conflict with the guidelines and then only adopted by the guidelines when enough UI designers break the guidelines to use the new approach.</div>

<div><br></div><div>For clarity, I'm not saying my proposal is necessarily better - I was just proposing it to see if folks here might find it useful, as I have in practice. I mean this sincerely: I do *not* take any offence if you all prefer to continue in the direction you were before I popped in. Whatever you folks come up with will certainly be better than anything we've had before, so I welcome it! More importantly, if anything I've offered so far has been found with discomfort or offence, I sincerely apologize. :-)</div>

<div><br></div><div><offtopic></div><div>I originally had some text here describing my intent to contribute to putting together a design pattern library. However, rather than derail this topic any more than I already have, feel free to contact me on via G+, via email, or on the VDG forum if you're interested in that topic.</div>

<div></offtopic></div><div><br></div><div>Thanks much for taking the time to consider what I've offered, and please don't be shy about moving in the direction you originally had planned,</div><div><br></div>

<div>Much respect,</div><div>Andrew Lake</div><div><br></div></div></div></div>