17:22:17 aday: but the activity view... I really can't understand how the search there could trigger a search in between apps instead than just filtering the windows. I know there are search plugins for searching in betweeen windows, but this is really something bad... I open a view, full of windows... thumbnails, and when I start searching, iI actually search somewhere else. 17:23:02 now... my idea was just to filter the windows, and present those.. Other option is that window thumbnails could replace what apps icons are now... like adding a top row with tumbnails... 17:23:28 other option, again... to keep what we have and add another search view (maybe to be triggered only by key-bindings) that just does it... 17:23:47 Trevinho: that's actually the first time i've heard that... i can see the point 17:24:03 really? :o 17:24:58 maybe, again is the fact I'm used to something else https://www.youtube.com/watch?v=Kuqn19Fq5i0 17:25:03 but, that's the point 17:25:20 how big an issue it is, i'm not sure, but there's certainly no clue about what can be search from there, until you search 17:26:14 something to look at next time we dig into the activities overview, possibly 17:26:28 exactly... I mean I see te point of having it in the app view 17:26:30 but te activity view.... 17:26:36 not realyl. 17:27:27 at the london hackfest one of the ideas we were working on only showed search above the app grid 17:29:54 Trevinho, in Unity you separated the dash and the window overview, right? 17:30:05 verdre: yes, so it's different 17:30:16 well, even in gnome there's such differencty though 17:30:40 as going to activity is just different when from there you go in app grid 17:31:12 Sorry for the uglyness, but something like this... 17:31:19 https://usercontent.irccloud-cdn.com/file/ZpJQWrTE/image.png image.png2.63MB • image/png 17:31:29 with smaller thumbs and put in an horizontal slider... 17:31:43 so that I can at least be precise in filtering 17:32:01 however, this is probably not the best solution 17:32:15 as I'd prefer to have a view just to filter windows 17:34:20 the issue with that is that you hit dead ends 17:34:50 you go to search for a window, but you've forgotten that you closed it a while ago. game over 17:35:15 yeah, sure... but like when you search for a file you deleted, or not tracked 17:35:30 the nice thing about activities overview search is that it follows a progression. search for an app - it's not running - launch it 17:35:42 search for an app - it's not installed - select it from software - install 17:35:57 it's quite forgiving 17:36:14 I'd be happy to had a Super+w (say) to open a such view only, eh :-D 17:36:25 well for apps yes, for files no 17:36:42 i guess we are missing a way to search for open windows though? 17:36:44 an anyway "No result found" is still fine, I mean, meh... you're search for something that isn't there 17:36:48 yep 17:37:00 I've a search selector (see the last results of that screennshot) 17:37:03 what if you combined the app and window search results? that's effectively what is happening - if an app is not running it is started and if an app is running, one of its windows is selected 17:37:04 last category 17:37:26 borschty: indeed, that could be better 17:37:29 I was thinking the same 17:37:30 can you search for a tab in firefox though? 17:37:35 but it won't give you great selection 17:37:40 or maybe turn the search results into something like the alt+tab app switcher 17:37:42 if we can't get that data... 17:37:49 aday: nope, well in old unity you could :-D, but... I mean 17:38:10 borschty: that could be better 17:38:15 Trevinho: is that a trick we could do here? 17:38:17 pressing down would let you select which of the windows of an app you want to switch to 17:38:28 like... I search for a window, then... the selected app icon is shown 17:38:38 if i select it, the closest result is selected 17:38:51 otherwise, I can go into the deep of it opening a window selector, inside the activity view 17:38:59 borschty: yeah, exacly that 17:39:17 — tbernard REALLY wants to make a better alt-tab that is integrated with the shell-overview 17:39:19 or even at enter, to present them when multiple 17:39:30 i think i'd sooner see explicit window search results 17:39:32 tbernard: agreedo 17:40:16 aday: that's something nice too. At the same time, that won't allow me to reorganize in workspaces. And I might just want to do that 17:40:24 so, we need to allow dnd for such elements 17:40:34 Trevinho, what i'm thinking of is two rows of search results, the first row shows the app icons, the second row shows the windows for the selected app 17:41:03 pressing down would allow you to select a specifc window using keyboard navigation 17:41:14 borschty: the same we have for alt+tab + down? 17:41:24 ahhh ok no then 17:41:25 yes, pretty much like that 17:41:53 I also i've to say we don't have to make hard to select other results harder (when multiple rows are there) 17:42:27 Or wait... wait.... well the most integrated would just be ... using the same we do for settings, let's say 17:42:45 i would limit this to one row for the windows 17:42:53 if you search for background you show the same for the pane and the app 17:43:49 then, if you search for a window, you show on the left side the app that owns them, and on the right one the windows which matched 17:43:59 that's probably the easiest solution 17:44:30 so organize window results per their partent app 17:44:33 and that's it 17:45:31 that would involve still quite a lot of key hits though (especially when they involves arrows, as they're far from actual keys), and I'm not a fan of it but at least you can just continue write to be more precise 17:46:17 To be fair, having results like that would solve the engineering problem, not the design though. I still think is wrong to present a list of window thumbnails, and then you search in an entire new world 17:47:10 plus not seeing the window thumbnail, sometimes could be problematic to discern, as titles could be similar or... even missing 17:47:30 another variant: only show the window row when there is more than one window and sort the first (app) and second (windows) row according to window title matches in addition to application title matches 17:47:39 maybe start a wiki? :-D 17:47:49 that way you can select windows by typing their name 17:47:51 or an issue, or whatever 17:48:02 sounds good to me" 17:48:05 ! 17:48:15 and the common case of a single window per app won't be changed 17:48:57 the only "issue" would be the second row expanding/collapsing depending on which app is currently selected in the first row 17:50:51 borschty: yeah, it's an option too... 17:51:18 aday: wiki? or where? 17:51:39 Trevinho: i don't really mind 17:51:45 I vote for opening an issue. 17:52:03 an issue's fine. otherwise, it could be a whiteboard page - https://wiki.gnome.org/Design/Whiteboards/ 17:52:58 Issues are the best way to get the community involved with the design process. Just look at how well the whole action-bar proposal in Nautilus worked out. 17:54:46 verdre: I agree 17:56:08 the design wiki pages always seem a bit like the plans for the intergalactic bypass in the hitchhiker's guide to the galaxy. nobody knows that they exist, even though they are publicly accessible 17:56:56 borschty: that can have its uses 17:57:29 sure