"Steve Davies" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Jul 2006 11:48:11 +0100:
> On 7/25/06, Charles Kerr wrote: > >> [Duncan wrote...] >> >> > [Suggestion: What about the] posting server a function of the posting >> > profile? http://bugzilla.gnome.org/show_bug.cgi?id=348667 >> >> I agree that this needs to make it into 1.0. >> >> Adding it to the posting profile makes sense, except for >> error-handling: I was wondering about that too, but decided I had to think about it a bit before I could suggest anything. The points below helped resolve the specifics of the question, but I'm not sure I have a solution as nice as the first part of the suggestion was. >> (1) how should Pan handle it when the posting server doesn't have all >> the groups listed in the new post's Newsgroups: header? > > I assume that the server will inform you of this fact when you send it > the headers. Basically I say log it and carry on :) If you get the > opportunity, then perhaps the offering a dialog box to say: >From what I know of NNTP, bad assumption. =8^( See, the thing is that it's not entirely uncommon to do that deliberately. Not all groups are on all servers (obviously), and it's considered valid to send to an expanded list of groups, some of which may not be on the posting server, as when the post propagates to other servers, it'll show up in all the groups that happen to be on the new server. Again, that's a valid and not entirely uncommon reason to post to groups not on a particular server. The group list DOES have to include ONE group on the server in question, however, or the post will be refused. > 1) Cancel posting entirely > 2) Continue - Send to reduced list of newsgroups > 3) Let me edit the posting again please. In light of the above, this isn't sufficient. Probably replace 2/continue with reduced list of groups with 2/continue as is. However, that doesn't seem as intuitive as I know Charles likes to have it, and it means adding an error dialog, thus forfeiting the bonus below. While forfeiting that bonus /might/ be best, I think there's an alternative. It's coming together as I write and I'm not fully satisfied with it, but maybe someone else can brainstorm an improvement. Anyway, throwing it out there... Given the above, that posting to more groups than the server has can't be assumed invalid... I'd suggest another go-back/post-anyway warning, similar to those (like the GNKSA warnings) PAN already has. If we're lucky, Charles can re-use an existing dialog template so we can squeeze by on the bonus on a technicality. =8^) Warning: The server for the posting profile assigned to this group doesn't carry all the groups you x-posted to. Go Back | Post Anyway Umm... something like that anyway. The wording isn't quite as intuitively simple as I'd like, but the idea seems to fit existing PAN warning solutions, anyway. To eliminate the most common form of the above, if the server chosen for the profile doesn't have a group, that profile could be deactivated/hidden as a choice in the posting server group preferences. (Unfortunately, due to the permutation below, plus possible complexity in getting this working right, this aspect may not be viable. It's likely simply too complex to implement in a working bug-free way, without either introducing way more betas than we want before 1.0, or forcing the feature to 1.1, neither of which is palatable.) The next permutation is the problem of what happens if a user switches the chosen server on a posting profile after building a list of groups using that profile. Let's see if there's a sane solution after dealing with the next issue Charles listed, however. The back/continue dialog's still reasonable, tho, I think. >> (2) how should Pan handle it when the user deletes the news server >> specified as the posting server in the profile? > > New dialog "Sorry, that server is used in...." Ouch! Again, that looks like it might be too complex to implement in a bug-free way in the time available, due to having to scan or keep track of the information for the "in <profile>" (I assume that's what you implied) part. Three-part (but small parts) solution? a) When implementing the posting-servers portion of posting-profiles, include what we can call a wildcard entry. This could be named "pan chooses", "automatic", "default", "any available", whatever. The implementation of that would be what pan's doing now, so it's essentially "free" in terms of implementation cost. b) With such a wildcard server entry, the logical (and expected/intuitive, well, as much as one would think of it in advance) handling in case of server deletion is to return the profile to the default entry. c) Maybe a tooltip or warning label to the effect of stating the above, in the selection? This isn't quite satisfying yet, but the idea again, that it would fit with the existing "additional help" solutions. On the satisfying thing... maybe I'm letting the not-perfect be the enemy of the good? IOW, perhaps it's not perfect, but I'm not sure there /is/ a fully satisfactory/perfect answer here, and one has to admit that while it /isn't/ entirely perfect, it's far better than the current (risky and unintuitive) solution, and with or without the tooltip/warning, behavior will be far less risky and far more intuitive than it is today. Perhaps that's "good", even if "not perfect". ... That leaves us with the unfinished business above -- what to do if the no posting group is on the chosen profile (and the single-group special-case version of same). Using the back/continue warning dialog above, is it possible to use the same template but only show the go back button (hide the post anyway)? Perhaps using that and some choice wording and variables, the same warning dialog can do double-duty as an error dialog, group(s) not on server, go back (single button)? >> Bonus points if the answers to these questions don't involve any >> complicated new GUI pieces. :) > > Like I say, just my 2c. I think the above is reasonably uncomplicated > which is usually a bonus. The question of these errors is a tough case. As I said, I'm not sure it's possible to get it "perfect". I'm also not sure if the idea squeezes into that bonus qualification or not, but at minimum, the suggested additional dialogs won't be /too/ complicated, two-choice max, and perhaps a tooltip, and will fit in with pan's existing GUI. So... more brainstorming absolutely welcome! If someone comes up with as "beautifully simple UI" (well, from a user perspective, I'm not sure I want to ask how complex it might be to implement, but both Charles and I seem to agree it needs done by 1.0 if possible) a second-half solution as I think my first-half was, I'll be duly impressed, as I certainly can't, or at least haven't yet! I guess another way to look at it is that not so many of the clients that have implemented automated multi-server do posting at all -- many are download-only! That certainly applies to both BNR2 and klibido, AFAIK. If these sorts of issues were simple, I'm sure it'd be rather more commonly implemented. The fact that it's not says something about the rather exclusive class of news client that pan now belongs to! =8^) The good news is that it doesn't take a perfectly implemented solution to beat no solution, hands down! =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
