| Summary: | Make enum RecvProtocol (prefs_account.h) extensible | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Claws Mail (GTK 2) | Reporter: | Avinash Sonawane <rootkea> | ||||
| Component: | Other | Assignee: | users | ||||
| Status: | NEW --- | ||||||
| Severity: | enhancement | ||||||
| Priority: | P3 | ||||||
| Version: | 3.17.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Attachments: |
|
||||||
Created attachment 1941 [details]
Rework recvtype in wizard.c
Attached patch makes "recvtype" store combobox index of desired default option, and the actual protocol number is pulled from the relevant row's data pointer in the combobox. That way we do not care whether the actual wanted default protocol has number 0 or not.
This is probably the simplest solution to this problem. A more proper solution (one that would ultimately likely simplify a lot more than just this) would be to modify our pref system to use GValue type for the default value in the PrefParam struct, but that's a rather complex change.
|
Hello! Regarding wizard.c (Line 170): {"recvtype", A_POP3, &tmpl.recvtype, P_INT, NULL, NULL, NULL}, Above code works just because A_POP3 is the first element of an 0-based enum. If any change is made to enum RecvProtocol which makes A_POP3 != 0 then that's a recipe for SegFault. Honestly, current arrangement isn't quite ideal for extending the receive protocols. Possible solutions: 1. use a static array of enum values ("0", "1", "2") or 2. simply use "0" instead of A_POP3 with a comment Above 2 approaches will be still tied to enum RecvProtocol and thus will require an update if the enum RecvProtocol is changed. But at least there wont be any SegFault.