2005-01-29, 07:52
a pm from btemp, and my response. i'm posting here so other devs can comment on it:
i think the password-setting part can be done within the cguipassword::isitemunlocked function that handles cfileitem objects (don't add it to the function that handles cshare objects, they aren't used for smb-based bookmarks).
you'll want to add a new switch case there for lock_mode_samba, and therein you can just prompt the user to enter a password. then you can take their input and inject it into the cfileitem's path property. if you wanted, you could also check the path to see if the username is specified; if not, you could prompt for that too and inject it into the path. you'll probably need a couple new entries in strings.xml for the prompt dialog headers. then set iresult to 0 in your switch case-- this will cause the function to "unlock" the bookmark and return true. at that point xbmc should try to access the smb share with the credentials you injected.
here's where the tricky part comes in, as you've noticed above--
csmbdirectory::getdirectory does not return the exact error it encounters (it only returns a bool), and way up above in the cgui*base::update functions there isn't even a check to find out if cvirtualdirectory::getdirectory worked-- it's just assumed that it did work. so if it failed, when update(strpath) is called in the cguiwindow*::onclick functions, the user ends up in a blank folder. this needs to be changed so that the getdirectory functions actually return a more descriptive int error (most likely the nt errno), and a bool override created to keep back compat for the other code that call these getdirectory functions. the cgui*base::update functions can be changed from void to returning the value from getdirectory.
then we can check way up in those cguiwindow*::onclick functions to see if update(strpath) worked, and if not, right there we have access to the cfileitem object-- we can flip the lockmode back on for the object and bail out rather than taking the user to an empty folder. it's not a minor change. let me know if you're just dying to do it anyway, otherwise i'll take a crack at it in the next few days.
devs, speak up if there's a better way to do this, if i'm not making sense, or if you think i'm just crazy...
(btemp @ jan. 29 2005,02:13 Wrote:slacker,
-omitted-
i have a design issue though with adding the samba passwords. i was looking for the best place and it seems that putting most the code in the csmbdirectory::getdirectory function would be optimal. that way, no matter how you got there (video, music, etc), it would run (no need to inject code elsewhere). i can do this ok but as i look into it, i wish i had more info being passed in than just the "path" (i.e., lock mode). of course, the path has the account and password and that was all that was needed for smb before but now i need to prompt if lock mode is 4.
i know i can look this up but it seems to me that the smb path mechanism needs to be revamped now what with lock mode, lock code and not to mention password, path and user name. maybe bookmarks should just be passed around in xbmc as completely contained entities (probably a structure) instead of a path string.
just a thought...
i think the password-setting part can be done within the cguipassword::isitemunlocked function that handles cfileitem objects (don't add it to the function that handles cshare objects, they aren't used for smb-based bookmarks).
you'll want to add a new switch case there for lock_mode_samba, and therein you can just prompt the user to enter a password. then you can take their input and inject it into the cfileitem's path property. if you wanted, you could also check the path to see if the username is specified; if not, you could prompt for that too and inject it into the path. you'll probably need a couple new entries in strings.xml for the prompt dialog headers. then set iresult to 0 in your switch case-- this will cause the function to "unlock" the bookmark and return true. at that point xbmc should try to access the smb share with the credentials you injected.
here's where the tricky part comes in, as you've noticed above--
csmbdirectory::getdirectory does not return the exact error it encounters (it only returns a bool), and way up above in the cgui*base::update functions there isn't even a check to find out if cvirtualdirectory::getdirectory worked-- it's just assumed that it did work. so if it failed, when update(strpath) is called in the cguiwindow*::onclick functions, the user ends up in a blank folder. this needs to be changed so that the getdirectory functions actually return a more descriptive int error (most likely the nt errno), and a bool override created to keep back compat for the other code that call these getdirectory functions. the cgui*base::update functions can be changed from void to returning the value from getdirectory.
then we can check way up in those cguiwindow*::onclick functions to see if update(strpath) worked, and if not, right there we have access to the cfileitem object-- we can flip the lockmode back on for the object and bail out rather than taking the user to an empty folder. it's not a minor change. let me know if you're just dying to do it anyway, otherwise i'll take a crack at it in the next few days.
devs, speak up if there's a better way to do this, if i'm not making sense, or if you think i'm just crazy...
