Summary: | krfb doesn't detect the IP address on FreeBSD | ||
---|---|---|---|
Product: | [Applications] krfb | Reporter: | Lauri Watts <lauri> |
Component: | general | Assignee: | tim |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | FreeBSD | ||
Latest Commit: | Version Fixed In: |
Description
Lauri Watts
2003-02-07 23:07:26 UTC
HEAD has been switched to getifaddrs() for addresses, which should work fine in FreeBSD. But I hesitate to backport this before a couple of people tested it with Solaris and other SVR4-based systems. Otherwise I fix it for BSDs and introduce new bugs or possibly even compilation errors for the others... The invitation address is only used to give the user a IP to tell to the invitee. It is not used for any other purpose and does not affect the actual functionality. It's a bit hard to tell if it's getting the address correctly, since krfb now segfaults on startup. I'll rebuild it with debugging and file that separately. I disagree that 'The invitation address is only used to give the user a IP to tell to the invitee. It is not used for any other purpose and does not affect the actual functionality' means that it's ok to have a completely incorrect address there though. It's not at all clear to users that this will eventually be put into an email where it can be edited, and I know from supporting them that many FreeBSD users don't bother to go any further when they see the information is incorrect and is not editable. I think just making the ip address editable would go a long way to solving this problem in any case. >>I think just making the ip address editable would go a long way to solving this problem in any case. << I'd rather use a label again instead of a non-editable text input. It has been changed from a label to a text input because the content of a label can not be copy&pasted. That was a huge mistake. The text input confused many people, because they thought they have to edit it when it shows a wrong address (beside other things, they tried to edit the password). krfb does not use the content, it is just a convenience feature for the user so she does not have to use ipconfig or a similar tool to find out her address. Having it editable would suggest that the user must correct it if the content is not correct. But the user does not have to - krfb always listens on all addresses, and the invitation is valid for all addresses. (it can also happen on other platforms that the IP address is not correct, for example behind a NAT firewall or when you have a multi-homed system with several IP addresses, but not every IP is reachable from every other network) >> [...] means that it's ok to have a completely incorrect address there though.<< No, of course not. I just wanted to say that it is usable, even if the confusing GUI may suggest that it is not. My problem with switching to getifaddrs() is that I am pretty sure that if I do this, I will break the implementation on other platforms and there will be several iterations of fixing other platforms that hopefully work now. Very few people with more or less exotic playforms seem to test the CVS versions (for obvious reasons, it only causes trouble :)... Getting IP addresses on Unix system is a portability nightmare, and krfb is the first KDE app in CVS that needs it. I think the problem is less that people feel they have to fix it there, and more that people don't seem to understand that they don't *have* to edit the address, and that it doesn't matter if it's wrong in the dialog, they get a chance to fix it in the invitation itself, if need be. Obviously, sending an invitation to someone who doesn't know your address, with the wrong info, is not going to be of use, and currently that's what many users assume will happen, and they give up right at that point without going on. I'm not sure how to solve that really. Perhaps hiding the detected ip address entirely or stating explicitly it's just a guess, and you can change it later, but that would clutter up the GUI. As for getting ip addresses, there's a couple of other apps that do so: Kinfocenter -> the nics module, which apparently works on FreeBSD -CURRENT lisa/lanbrowsing which does get the ip address right for me at least, although it guesses the netmask wrong, but that's not anything krfb needs is it? there might be some inspiration there. I read that Thiego Maciera is looking at a lib between Qt and KDE for handling this kind of thing, it's something that the KDE/FreeBSD team have considered doing as well, although we haven't started yet (isn't that always the way.) Maybe that will be the longterm answer. >> I think the problem is less that people feel they have to fix it there, and more that people don't seem to understand that they don't *have* to edit the address, and that it doesn't matter if it's wrong in the dialog, they get a chance to fix it in the invitation itself, if need be. << I think that a label would change the perception of the IP address. People would think "wrong Ip address, bad program" (assuming that they know about IP addresses at all), but they would not think about the possibility of editing it. >>I'm not sure how to solve that really. Perhaps hiding the detected ip address entirely or stating explicitly it's just a guess, and you can change it later, but that would clutter up the GUI. << Yes, right now there is already more text than most people will read. I am currently thinking about a concept to reduce and restructure the text (using 'tooltip links' similar to those in some WinXP dialogs) that could solve this. >>Kinfocenter -> the nics module, which apparently works on FreeBSD -CURRENT lisa/lanbrowsing which does get the ip address right for me at least, although it guesses the netmask wrong, but that's not anything krfb needs is it?<< getifaddrs(), which is used in HEAD, is supposed to be the clean way to get the interfaces. The function originated in BSDs and has recently been introduced into glibc as well, so it's on the way to become the standard. I just hesitate to backport the code to 3.1, because of Solaris and other SVR4 Unices that don't have it and I don't know how portable the fall-back code is (that I took from glibc). This is fixed and working as expected in HEAD, and as Tim says, not readily backportable. Closing. |