Merge filters and contextual filters into one feature

Isn't there a big technical difference?

For example arguments have things like default argument plugin/validator plugins/summaries.
At least a) and b) could be somehow makes sense for filters, too.

Just imagine of a) exposed form values as default filter plugin or a validator plugin to check valid input of users to exposed forms.
... Just thinking...

Not really sure. The new UI has two nicely designed screens for the filters & contextual filters. Cramming that into a single dialog would not change much, and I'm not sure how positive the result would be.

Of course, having arguments and filters be on the same level with features (and/or, operators) would be great. One more related issue:
#1088846: And/or in arguments

Regarding to the issue I raised here #1088846: And/or in arguments, I think it would be good to have them merged into one "Filters" section. Whether they're contextual or not is a just filter specificity in the end. It would automatically solve the and/or issue for arguments, since arguments would be filters too.

For what it's worth, I agree with Letharion's point of view.

I've tried to summarize why I think so, and an alternative approach, on the following sandbox project: http://drupal.org/sandbox/itangalo/1086472 ("Views arguments in filters"). From the description:

* Many people find it difficult to wrap their head around how arguments work.
* It is not possible to use operators on arguments, for example to show all nodes created *after* the timestamp value you provide in an argument, or display all the nodes that in their title *contain* the word/phrase in the argument. There is just "equals" or "not equals". (Unless you more or less code your own argument handlers, which would end up a special case that few others can make use of.)

(It's not a long text, but I don't want to paste it all here.)

Separating out the filtering functionality from argument handling seems natural to me – it would increase usability and flexibility, without losing any of the power in Views.

So you're proposing to make arguments never add anything to the query, always pass the value to a filter instead?
Or a complete UI merge (which would be quite difficult to achieve at this point)?

Yep! And I'm quite sure that Letharion has the same view – argument input should still be handled by the current arguments handling, but the actual filtering should be done at the filter settings.

@Letharion: Please shout out loud if I'm misinterpreting your ideas!

As far as I can see, he wants to kill arguments completely and move everything to the filter edit UI.

Earl disagreed because arguments are not just about filtering, but " Arguments can completely turn a view into something else, though.".

If you need a way to use or/and in the filter see http://drupal.org/node/1088846#comment-4197044

Right now, I think the best solution for everyone is to enable filters to extract their value from an argument.

It's similar to exposed handling, but:

1) there is no widget
2) you're limited to string input.

Arguments are powerful and they do a lot. Filtering is only part of their job. Some arguments modify other arguments. Some arguments simply ensure there is input or no input. Arguments have validation and argument defaults are a cheap, hacky way to try and get data from context. And then there's summary queries, which completely transforms the view into something special.

Arguments can't be done away with; instead they should "simply" be able to pass their data off. Then you can have the global: null argument that can still do whatever validation/default stuff necessary and hold the data for a filter to grab. That's my view.

I completely agree with #11. Almost.

2) you're limited to string input.

Why limit to string input? I like the idea of a button next to "Expose" saying "Get from argument", that when clicked changes the input widgets for the filter to select lists showing all available arguments.

Lets continue this discussion at #357082: Pull filter value from an argument? then. It already has a sample implementation and thoughts on the UI (putting it in arguments VS putting it in filters)