Newsgroup: it.comp.software.newsreader
Titolo: Watch/Ignore

Sto implementando queste azioni in XPN, al momento solo sugli articoli,
in seguito le estenderò ai sottothread.
Per il watch ho fatto in modo che se un articolo è watched per tutte le
risposte a questo vengono scaricati automaticamente anche i body.
Per l'ignore però non mi è molto chiaro come muovermi, come si
comportano gli altri newsreader quando si imposta l'ignore su di un
articolo?
-- 
Someday, we'll look back on this, laugh nervously, and change the
subject.
 
 |\ |       |HomePage   : 
http://nem01.altervista.org
 | \|emesis |XPN (my nr): 
http://xpn.altervista.org

 articolo?
Per quanto riguarda Moz/TB, per come l'ho configurati io, i nuovi post
nel thread ignorato semplicemente mi "scompaiono", dato che io non li
visualizzo neppure; gli headers ovviamente vengono scaricati ma i bodies
no. Nel caso visualizzi anche i thread ignorati, i nuovi messaggi in
quei thread mi vengono automaticamente messi come già letti.
Sperando di essere stato esaustivo..
-- 
Luca Amicone
Laverda "Ciumaca" 350
Ducati "Erede" 800 Sport

 articolo?
Dalla guida di Dialog
| The ignore flag is propagated to follow-ups and new follow-ups to
| this article are automatically marked read
E si scaricano solamente i campi Xover per i messaggi già letti. Così
si vede comunque l'andamento del thread ed eventualmente, se interessa,
si possono scaricare anche i corpi dei messaggi che possono
interessare. 
-- 
daRkSidE, 01/01/2005 21.39.19
[06/24 - The Best Of The Columbia Years 1943-1952 (Disc 3)] Frank
Sinatra: You're My Girl

 E si scaricano solamente i campi Xover per i messaggi già letti. 
Domando: Dialog ha ereditato da Agent il problema di watch e ignore che non
rientrano nelle regole di priorità dei normali filtri? In Agent, se ho per
esempio un filtro watch impostato su un autore, i messaggi di questo verranno
scaricati anche nei thread che ho ignorato con i, a prescindere dalla priorità
che ho dato allo watch. Se poi il filtro sull'autore è di tipo "watch thread",
quello disattiva completamente qualsiasi ignore dato con i.
IMO, questo è il problema principale da porsi quando si impostano le azioni
watch e ignore attivate "al volo" sul thread. E' un po' che ci penso, per me
una soluzione abbastanza completa potrebbe essere:
w,i            - watch, ignore thread in tutti i gruppi sottoscritti
shift+w,i      - watch, ignore thread nello stesso gruppo
ctrl+w,i       - watch, ignore subthread nello stesso gruppo 
ctrl+shift+w,i - apre la finestra di dialogo per l'impostazione del filtro 
                 singolo.
Tutti i filtri così attivati dovrebbero rientrare nello stesso meccanismo di
priorità, con i primi tre che hanno una priorità impostata per default,
modificabile così come tutte le altre caratteristiche (eventualmente in modo
basato sul gruppo). Così si ha la scelta, impostando un filtro dell'ultimo
tipo, se fargli superare gli altri o no.
-- 
Luca - e-mail: p.stevens at 
libero.it

 quello disattiva completamente qualsiasi ignore dato con i.
Prendo spunto da questo post per farvi anche un'altra domanda come vanno
risolte le priorità tra watch/ignore. Non mi riferisco al caso che
esprimi tu Luca cioè di filtri vs impostazioni manuali, ma al caso più
semplice per cui imposti manualmente il watch e l'ignore.
Supponiamo di avere impostato un watch su un subthread, e poi
all'interno di questo subthread vado ad impostare un ignore, cosa
prevale il watch o l'ignore? E nel caso inverso?
-- 
Do not be led astray onto the path of virtue.


 interessare. 
OK, in ogni caso quindi l'eventuale watch/ignore si propaga al subthread
giusto? O si ferma ai followup di primo livello?
-- 
"Errare e' umano, perdonare e' fuori dalle specifiche del sistema
operativo."


 giusto? O si ferma ai followup di primo livello?
Si propaga.
-- 
Fact of life #15: Heads bleed, walls don't.

 prevale il watch o l'ignore? E nel caso inverso?
L'ultimo che metti, quale che sia.


 articolo?
Il top IMHO è MacSoup. Se premi "+" o "-" metti il watch/ignore sul
subthread, se premi "alt" durante l'operazione estende al thread intero.
Per gli articoli ignorati vengono scaricati solo gli header. I body già
presenti vengono mantenuti.


 quello disattiva completamente qualsiasi ignore dato con i.
Non ho provato, ma in genere i filtri prevalgono sull'ignore/watch.
Per me la soluzione più completa, e semplice, sarebbe inserire un parametro
nei filtri per stabilire se questo è scavalcabile o meno.



-- 
daRkSidE, 02/01/2005 23.41.30
[10/16 - Absolute Janis (Disc 1)] Janis Joplin: I'll drown in my own
tears

 descrivi, lavora sul sottothread.
Beh no, al momento (ma ho intenzione di cambiare questa cosa) il
watch/ignore funziona solo sulle risposte "dirette" agli articoli
watchati/ignorati non sulle risposte delle risposte ...
-- 
I spilled spot remover on my dog. He's gone now.



Si questo gia l'avevo visto, ma al momento voglio prima rodare un
qualcosa di più semplice. ;-)
-- 
Good judgment comes from experience, and a lotta that comes from bad
judgment.


 basta applicarlo sull'articolo che apre il thread.
Io automatizzerei la cosa, con una scorciatoia da tastiera che eviti di
doversi spostare in cima al thread. Non so però quanto sia complesso farlo, mi
sono sempre chiesto del perché questa funzione, per me banale, è così rara nei
newsreader.


Mentre io pensavo ad una intro simpatica "Luca" scriveva:

Beh di per se non è complessa, dipende molto da come il software
archivia (anche logicamente) gli articoli. Se ad esempio si crea una
certa struttura "Thread" che contiene tutti gli articoli di un thread
allora la cosa è semplice, altrimenti possono sorgere alcuni inghippi.
Io ad esempio gli articoli li archivio semplicemente in una lista, e poi
i thread li ricreo ogni volta che entri nel gruppo. Per me non esiste
nessuna entità thread, quindi io per operare su articoli diversi da
quello selezionato (ad esempio impostare il watch sul subthread)
sostanzialmente uso le references. Tecnicamente trovare il capothread è
facile basta prendere il primo mid nelle references ... ma metti che
tale articolo ad esempio è stato purgato/cancellato o qualsiasi cosa e
quindi non c'è come ti comporti? Puoi prendere il secondo ....
Insomma una cosa che logicamente è banale può diventare ... ahem
scassaballe per il programmatore, quindi la cosa più semplice è lasciare
la libertà all'utente ;-)
-- 
Go ahead, make my data!


 L'ultimo che metti, quale che sia.
Già.
-- 
daRkSidE, 05/01/2005 12.26.48
[06/11 - Portishead] Portishead: Humming

 ignorato con i, a prescindere dalla priorità che ho dato allo watch.
Non so. Bisognerebbe fare delle prove, che non sono subito
semplicissime.
-- 
daRkSidE, 05/01/2005 10.34.15
[03/12 - TNT] Tortoise: ten-day interval

 la libertà all'utente ;-)
Lo so, noi utenti siamo gente dura :)


 messaggi venga inserito nel thread e messo in watch. 
Se cerchi gli articoli che nelle references hanno i dei due m-id di cui
sopra allora troverai il *sub_thread*, dovresti ricercare tutti gli
articoli che hanno almeno un m-id nelle references in comune con quelli
presenti nelle references dei due articoli, in effetti in un mondo
perfetto (in cui i newsreader tagliano correttamente le references)
dovrebbe bastare controllare il primo m-id nelle references.
Ad ogni modo dubito che anche quei newsreader che si implementano il
watch thread si comportino in questo modo. Ho la sensazione che il watch
thread sia applicato solo a quello che lui ti sta mostrando come thread
(senza quindi articoli usciti fuori perchè non hai il thread completo).
-- 
If I worked as much as others, I would do as little as they.


e aggiungere i nuovi reference di questi messaggi via via che vengono inclusi.
Se però spezzetti i thread al cambio di subject hai già un problema in
più, ché in quel caso i filtri sarebbero applicati anche agli articoli
che per te fanno parte di altri thread...
-- 
Ciao, Massimo | ICQ# 57669970 | Jabber: 
pet...@jabber.linux.it
- La bellezza salverà il mondo. -

 (senza quindi articoli usciti fuori perchè non hai il thread completo).
Mi pare che il comportamento giusto è quello che ho malamente descritto
all'inizio: un thread dev'essere composto dall'unione di tutte le coppie di
articoli che hanno almeno un reference in comune. Come fare per assegnare
dinamicamente i messaggi alla "griglia" dei thread in base a questo criterio,
man mano che vengono purgati i vecchi e ne arrivano di nuovi, vedo che è un
problema tosto tosto, se uno vuole tenere conto della possibilità che i
reference possano essere scassati a piacimento. Ma sono sicuro che un modo 
c'è :-)


 che per te fanno parte di altri thread...
Un problema per volta, direi :)


 Un problema per volta, direi :)
E invece no, è proprio questo tipo di problemini nascosti che spinge il
programmatore a pensare "ma vaffanculo il watch thread" ;-)
-- 
First, draw the curve; then, plot the data.
