View Single Post
Posts: 134 | Thanked: 57 times | Joined on Mar 2008 @ South Bend IN
#73
Originally Posted by pipeline View Post
Update : now that i think about it your probably parsing the ~file to see the hildon default? If so we can package together an unused defaults.list (with all maemo apps as defaults) for reference and hide it in /usr/lib/dbus-switchboard for you to use intead of ~ files since my current implementation of those ~ files is not reliable enough to use anymore (useless if you install/upgrade more than once on any given os flash)
Thats fine, I just used that because it was handy on the defaults, and then rinsed and repeated for the uri's. I didn't define a global for the "base" file, but I think that the file paths are used in only two lines of code, one each for loading the info.

Originally Posted by pipeline View Post
About sudoers : My first though was separate registration into separate .py file whose sole purpose is to update the defaults.list, but now that i see your gui i think it might be better to sudo the entire dbus-switchboard-gui python file and run the whole program as root... thats less of a hole than leaving capability to copy arbitratry file and overwrite defaults.list as 'user'... less important because its a tablet, but probably more acceptable to long time linux users. Sudo on the gui at least the user sees what hes about to do rather than it getting overwritten as a blip in someone elses ui-less script to cp that file.
That makes sense, i think. The way I read it, we would create a sudo entry for the switchboard gui and run it with sudo instead of just the cp command. Which keeps the defaults.list file under lock and key, so some one can't randomly type "sudo rm defaults.list" [DISCLAIMER: DO NOT TYPE THIS!!!!!!!!!!!!!].


I'm going to have to take a second look at the dbus mime calls. It looked like the dbus services received a method call of "mime_open" from the internal maemo mime handler. Since switchboard gets called instead of that dbus method, I thought that switchboard could instead place the osso.rpc call directly to the service. I only looked at it long enough to get my audio/video running though, I could have been way off base. I really wish there was documentation that came with all of the services, it sure would be easier to wrap my head around (If some one does know of said documentation, I'd love to be directed to it!)

Thanks for taking a look at it, I'm sure you're going to have fun ironing out various bugs. I do apologize, I forgot to mention that I fixed my implementation of tracking if the file was saved, and did not implement your new version that did the same (thanks to me forgetting to update to 1.2.2 before editing.)

Thanks for all the hard work!
 

The Following User Says Thank You to hvacengi For This Useful Post: