add a way to kill the mutex between del, new/old and un/read

[dominiquefortin]

I use the del/^del, new/old, unread/read and flag/^flag as simple flags to categorize the headers. To do so, I desabled all option that would change the flag status after event like "Mark new headers old on close view".

Now all I need for this to work perfectly is to have an option to disable the mutual exclusion between the del/^del, new/old, unread/read and flag/^flag checkboxes. So that, for example, showing ONLY the deleted unread and old headers would be possible.

Thank you.

[alex]

the flags are not independed on purpose, i added that behaviour in one of first releases i think to add some logic.

i see the flag option is independent, read/new/del are mutually exclusive, just if not to assign new meanings they should be.

also flags sometimes behave differently, e.g. if you mark deleted headers for download they will be automatically undeleted.

you can create a view filter (in the filter editor) which does what you want, then you just select the filter in the filter combo box, with those filters there is no such prompting logic.

[dominiquefortin]

you can create a view filter (in the filter editor) which does what you want, then you just select the filter in the filter combo box, with those filters there is no such prompting logic.

No, you can't categorize a list of heterogeneous names using a named pattern (here the wildmat filter) when the list is long. It is only feasible when the list is small or when all the name contains alot of homogenous patterns. The only way then to categorize a list of heterogeneous names is to use an external property (that's where the diferent flags commes in handy).

Also, I use the custom collection as a backup to when the auto collection for some reason does work on a particular series of homogenous headers. Anyway, it would defeat the purpose of collections by using it to aggregate heterogeneous headers (it would be like having no collection if the list is very long).

If your using a BYTE to store the flags then it looks like there's 1 bit left (there's more left if your using a WORD or DWORD). It would be intersting if you could make them available as custom flags that we could use to fliter.

Thank you.

[alex]

no, what i mean how you can use the new/read/del flags without the filter unchecking flags.

edit menu->filter editor.

then you can create a filter like new&read, read&del or whatever you need like "read" - "messages are read", "new" - "messages are new"

then e.g. if you you can create composite filter named

read&old

with the condition:

read&^new

with features there is some work ahead like little more work on server and file manager/par2 so it may be some time until i'm back to small features, with additional flags though it is not so clear how to reflect them in the interface and where to draw them (it is visual c++ the interface is not very flexible). also i'm not sure any reserve bits left per record, most likely not.

[dominiquefortin]

The problem with filters (the ones made by "filter editor") is that their strenght reside in isolating headers with a particular pattern in their subject (, author, lines, ...). But, when there are no patterns, like when I select collections based on likes/dislikes for futur download, I would have to make a wildmat pattern with sometines between 100 to 200 items in it. Not very practical. You could say that there exist one general flag called "flag" that can be used for this. Well, I do used it, but one isn't enough. That is why i'm also using new/old, un/read, del/^del. If you're wandering what do I do with headers I'm no longer interested in; they get purged.

Usenet at it's origine was used like emails with the difference that a particular mailbox (a newsgroup) was readable by many. The content was text. But, today, most of us that uses program like Usenet Explorer (a very dear program of mine, thank you) for binaries. So, flags like new/old and un/read lose a little bit of their previous meaning for groups that get 100 thousands et 200 thousands new post a day (the collection feature is what makes this enjoyable).

i added that behaviour in one of first releases i think to add some logic.

I remenber when it was added and at the time I though it was a minor nousance. It is only a user interface behaviour so I'm sure it's not a big thing to change back to what it used to be before. That is, no predefined mutual exclusion. This way the user can decide how to use it.

so it may be some time until i'm back to small features

It's your software and you're the project manager. I'm only argumenting my point.

with additional flags though it is not so clear how to reflect them in the interface and where to draw them (it is visual c++ the interface is not very flexible). also i'm not sure any reserve bits left per record, most likely not.

Adding new flags would certainly be a great thing. How to do it, might be a more difficult thing as anything in designing user interface. But visual feedback should always be king. So something that exists but can't be seen is not very usefull. For example, the subject name can be colored 3 ways magenta, grey and black depanding on the state of the new/old and un/read flags. Well, there is one color missing. 2 bits = 4 states. In my opinion, headers new and read shouldn't be the same color as headers old and read. A new color should be added for one of the two.

I have one suggestion. This is only about the visual representation that this could take. Since the flags new/old, un/read, ^/body, ^/error, ^/del are more system state and the flag ^/flag is more a user state, a new column could be added just for the user state. An additonal colunm for just one flag would not be very economical, but for 8 it would (each one with a different color). There would be additional checkboxs on the bar that would allow the user to chose a conjunction of colored flags.

also i'm not sure any reserve bits left per record, most likely not.

For this work, new bits might be nedded.

[alex]

no, in the filter editor you can also add filters "messages" are "new", "read" etc. and in any combination without mutual exclusion.

then simple subject/author filters can be done using the quick filter.

it is questionable to add something which only few people would use, actually when text usenet was more popular such requests about further filter refinements were more frequent, right now i don't feel much user interest here.