Filter feature

Jun 18, 2013 at 3:02 PM
Edited Jun 18, 2013 at 3:19 PM
I'm actually grabbing some informations about a filter implementation that would look like the one implemented in wireshark.

So we would have to create our own grammar for the filtering process, analyze the query and filter the rows based on this analyze.

I've started a document on google docs, since it let me edit it remotely.
Here

I don't know if you have a gmail address dirk, it would allow you to edit it.

Any other toughts will be written in the linked document.
Coordinator
Jun 18, 2013 at 8:45 PM
Edited Jun 18, 2013 at 8:49 PM
Hi Gwen,

I think it would be great if we could have a marker filter (combobox with checkbox for each type of marker) above the marker column. Do you think you can do it or do you need help? I could supply sample show-casing the checkbox with idea. You could then integrate it just like you integrated the listbox, although, the combobox with checkboxes is not that different - I am just not sure what the selected element should be since we could select a text and color marker (for example) expecting to be shown rows that contain either or both of these items. Maybe there is another (better) control to do this?

I am not sure why you use Google docs, you know, you can do the same with the Wiki on codeplex and you have full access... I have a Google account but almost never ever use it so I'll write my comments here :) Did you document the multiple view thing we were talking about in the last mail?

I would go for the literal version (equal instead of '==' as it would work for more people - even those who debug their VB application, and the length does not really matter if you have autocomplete or some other type of help like this...). Filtering for timestamps would be great - why is that so complicated? We could at least try something like TimeStamp >= "1.1.2013" AND TimeStamp <= "1.1.2014" this way it would be really useful and not much more complexity on the grammar side, unless I am overlooking something?

--- Here is another new fold filter idea ----------------------------
There is one other way of filtering that I realized the other day. You know, when you set a marker you might also want to set a range for it. I can imagine that someone like Francois might look at his logged pattern and be thinking:

Textmarker 1: oh, here is pattern A (next 50 entries)
Textmarker 2: ...and here is pattern B (next 75 entries)
Textmarker 3: and this is where pattern A breaks (after 45 entries, why?)

A good way for supporting these kind of ranges would be something like a collapse region control that we have in Visual Studio on the left side. This kind of folding technique is also in AvalonEdit and hence in Edi. I am wondering if we should apply these folds to our marker scenario? Let me know if that sounds interesting...

--- Here is another new fold filter idea ----------------------------

How about the background processing are you getting along with it? You know it would be really good if we can setup the processing such that users cannot launch multiple task that will not work together for technical reasons. The same goes for the commanding, we should make sure commands are only available when they can safely be executed. On the whole, this should result in a more stable and easy to use product. So, I know its boring because its not a new feature, but its really worth it since stability and usability are important things to have these days...

Cheers Dirk
Jun 19, 2013 at 10:00 AM
Hi,

The reason I use google Docs is fisrtly, I'm really confortable with it, I use it for a very long time and. And my very close friends and I usually share our work so we can give each other feedbacks and ideas toward our work. I'll copy paste the content of this document once it will be done and close. I'm fine with the fact that you comment here, I'll also follow the evolution of this feature on codeplex.

I've been speaking with Francois, he doesn't have much time to work with me on yalvlib this month. For the textmarker range, I'm not sure it will be useful. The aim of the text,arker is really the point out the lines that occurs an error or the lines that you really HAVE TO read. If we apply a textmarker on 10+ lines I think it lose his interest. And since it is pretty easy to apply a marker to several lines by usig mouse or shift click I'm not sure that feature is that useful.

For the background processing, I agree it would be a really nice advancement for the application. But I'm wondering if it wouldn't be more important to work firstly on the core of the project, the model. I think the implementation of the Filter feature has a higher priority than this.

Maybe we could open a new discussion about this, it will be in standby state for few times but at least it will be written somewhere.
Jul 3, 2013 at 10:01 AM
Edited Jul 3, 2013 at 10:04 AM
So, I've been working on this feature the past week. It works and I'm about to implement it on Yalv.

I've been thinking about the fact that we don't want to reload all the data everytime we apply a filter on the entries. I think the best way is to add a boolean property "Visible" on the LogEntryRowViewModel and then add a trigger in the GridStyle.xaml that will collapse the row in the datagrid if the value is False.

I this way we just have to refresh the grid and the row will be hidden depending on this property value.

I'm also searching the best emplacement for the filter input. For the moment I will add a tab next to the message and throwable properties on the bottom right of the app. It's certainly not the ideal place, but I want to implement the behaviour and then I'll work on the view.

:)
Jul 3, 2013 at 7:57 PM
Hi there,

just to summarize the job that has been done so far on the filtering system.

A grammar has been created to write queries against a log workspace in a human readable language.
A textual query will then be parsed via a parser. The resulted tree structure is then translated into the query language (in c#) and interpreted against each log entry in the model.

If a log entry satisfies the query, then it stays visible in the view. If not, then it should disappear from the view.
Queries will also be saved in the workspace and therefore serialized in the database.

Now, the vision I have is that all the filtering already existing (level as well as columns) should later use the universal query language.
Only one filtering system with several clients: the radio button for level, the columns text boxes, the query text box and more in the future.

Now coming back from the usability of the tool. I see the async operations as secondary priority. Having the app freezing for some seconds does not scare me. I am willing to accept that because I know the tool is dealing with MBs of logs and there is a lot of processing.

The real value is to be able to filter in a powerful and elegant manner.

F.
Jul 15, 2013 at 2:21 PM
Edited Jul 15, 2013 at 2:35 PM
So i've pushed the filter feature to the project.
Few explainations :

I've coupled the CustomFilter i've worked on with the filter property of the datagrid. This was the only solution which allow the filtering going almost smoothly. If you enter a query and apply the filter, the Filtetring state of the application wil be turn to true (Filtering icon)
// Evaluate text filters if we are in filter mode, otherwise, display EVERY item!
            if (IsFiltered)
            {
                if (MatchTextFilterColumn(mDataGridColumns, logitemVm.Entry) == false)
                    return false;
                if (_filterViewModel.Evaluate(logitemVm.Entry) == false)
                    return false;
            }
So at the moment the filter is using textcolumns AND the customfilters. So we were thinking about fusionning the two way of filtering into a single one BUT the fact that the column filtering allow the user to reduce the number of log entries only by typing the beginning of the value he wants instead of typing the whole filtering value is a big plus... To be discuss

How to use the filtering feature :

I've added the filter into a tab next to the throwable and message tabs (bottom right)

Query format : NameProperty (NOT)(equals / contains) value

The query will be added into a list beside the query input, allowing the user to set the queries active / inactive.
If the user put several queries, the filtering will be done incrementally. It means that if the user type for example

Message contains error
TextMarkerAuhtor equals Gwen


The entries available will be the ones that have a message containing "error" AND they have a textmarker associated which author is "Gwen"
It's equivalent to (Message contains error) AND (TextMarkerAuhtor equals Gwen)

I've also worked on the Autocompletion feature. I'm still having some issues to bind the list of string I want the textbox to display on the view. I'll let you know if I reach a solution for this :)

Don't hesitate to tell me if something looks weird or is not understandable

Gwen.