"Charles Kerr" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 04 Jul 2006 19:51:07 -0500:
> For a better fix, I like Walt's "disable server" toggle idea. > It would be in the server edit dialog. Pan could also show a > "do you want to disable server?" dialog when it's unable to connect. > Walt, David, does this sound right? I like this idea! =8^) > Anyway, the idea of having an 'active' server a la 0.14 > is a nonstarter IMO as it conflicts with multiserver downloads. > I'm happy to hear about specific problems and fixing them with > refinements to the current scheme, though. The biggest problem ATM is lack of group level state, IMO. One of the first things for 1.1 should be yougetting that back. I'm not sure how you envision it, but I envision a "group properties" dialog much like the server or profile properties. Some group state, stuff like the filter toggles, wouldn't be displayed altho it would be tracked, as it should be obvious. (Alternatively, put that on a tab, showing everything tracked, for consistency.) However, stuff like default posting profile SHOULD go in group properties. (This should I believe solve the obviousness problem with the former method, that you had mentioned to me.) Combine that with an addition to the posting profile choosing which server to use when posting using it, and that neatly solves the which server to post to question as well -- in a pretty intuitive manner IMO. (Note that if this is done, a posting profile set to post to a particular server would need to be disabled for any groups not carried on that server.) The default save location should also go in group properties, solving /that/ problem. Partially solving the problem of the topic, tho I'm not sure of the best way to set up the group properties interface for it, would be what servers to poll for a particular group. The best I've come up with is a separate tab on group properties, with checkboxes for each server. Unchecked, that server will be ignored when polling that group. Checked, it'll be used if the group exists on that server. (Optionally if you or someone wants to program it, servers where the group didn't exist would be disabled, but that's not required.) By default all servers would be checked, of course, yielding the current behavior. The server properties activation option we are considering now would then become a sort of global option, to the group-local option this proposes. Another group property could be whether to include it when "download headers for all groups" is done. This way, a group could be deactivated for awhile, not updating unless group update is chosen for that group. then reactivated when desired, without having to unsubscribe/resubscribe. As I said, group state retention is IMO the biggest thing still lacking, so should be top priority for 1.1. Another "big" feature in old-pan still missing from new pan is customized hotkeys (I'd love to see that before 1.0, but don't know how big a project it'll be or whether it would be destabilizing). Still another is group categories. In old-pan, as you can see from this thread, group categorization was often achieved by setting up multiple servers, one for each category. (In fact, I distinctly remember suggesting that as a solution, to a number of folks wanting categories.) Obviously, without the concept of an active server, that won't work for new-pan, so before too long, group categories/folders are going to be a must. -- 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
