Hi, John Stowers wrote: > a) > The build provess for hippo > (http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on > account of things for windows and osx in there. This includes a > dependency on firefox and a huge bunch of statically built libraries. > This seems a bit excessive.
The system copies of the libs are used on Linux. We do need to figure out some kind of directory rearrangement so you don't have to check them internalized copies out of svn on Linux. But, I don't think there is any non-developer impact here. The negative is purely that right now the svn module has a bunch of stuff in it irrelevant to Linux taking up disk space. Suggestions are welcome. I don't think windows portability is a negative though, any more than it is for gtk or gimp or whatever. > b) > There is no way to login to programatically to online desktop using > either the dbus api or another manner. This is different to many many > other web apis and makes it difficult to reliably use the api from > outside mugshot. We discussed this some in private mail. I'm still not really understanding what you mean. The way you're doing other APIs is that you're using a model where individual apps log in to web sites. Our model is that the whole desktop - i.e. the data-engine daemon - logs in to online.gnome.org, and no other app needs to log in. I think it's clearly a downgrade/sucky if every app has its own login dialog and you have to log in 10 times if 10 apps use the data engine. As I said in private email, we can have an API where you can supply the login cookie, so you could open online.gnome.org/who-are-you, log in, get the cookie, and give it to the data engine thus logging in the whole desktop. But, this is obviously a hacky workaround for the fact that the browser used in your app is not sharing cookies with the user's main browser in the first place. But, I think easier and just about as good is to simply do "gnome-open http://online.gnome.org/who-are-you"; You really need not worry about this at all in theory, because a reasonable "online desktop" default config will have a big login button on whatever its panel thing is (bigboard, gnome-panel, whatever) if the user is not logged in to online.gnome.org. So individual apps don't need to offer login at all really. What I think would be wrong is to have multiple login states, i.e. have a situation where one app is logged in but not another app. > c) > Continuing on from the above point, the current method of monitoring > and parsing the cookie file to log in, while cute, is not something I > totally grok. While I see the point of it all (login once, and then > access the services from any app) It never gets close to solving the > real problem, sharing authenticating information from the browser with > the rest of the system. I don't understand what you mean here. (I don't know why we want to share auth info from the browser with the rest of the system.) > web-login-driver is neither here nor there as > a solution web-login-driver has nothing to do with the login of the data engine to online.gnome.org. All it does is potentially "prefill" login info for non-online.gnome.org sites, see bigboard/bigboard/accounts.py > The whole thing seems to depend on firefox/gecko quite heavily. How > does this fit in with gtk/webkit? The cookie thing does not depend on those heavily, it supports a couple of browsers and is easy to extend to support more. If we eventually implement what I think is the real solution, that all apps on the desktop share the same http stack (meaning, cookies, proxy settings, and cache), then there may be some work to get the different browser engines supporting the same cookies/proxy/cache/etc. How hard it is I don't know. But work like this is the price of diversity, and if nobody does the work apparently the diversity is not worthwhile. > d) > The mugshot GUI runs in the same process as data-model-engine. I > realise you are working to remedy this. Right. > e) > Can you explain the relevance of pyddm if one can communicate with > data-model-engine over DBus to acomplish the same functionality? pyddm is a python library that communicates to data-model-engine over dbus. > f) > Work is ongoing in Conduit to make it play nicely with OD. We should > have some things to show soon (minus gross login hack due to b+c. Lets > talk about standard places in online desktop where we can store > peoples login names to different sites (i.e what is my flickr > username). This is probbably a documentation issue where object paths > and such just need to be spec'd out somewhere. I would like to do this with an approach similar to bigboard/bigboard/accounts.py - see recent thread on the online desktop list - but in short, I think the flickr username should be in gconf, and the flickr password in gnome-keyring. Then we use the online prefs sync feature to sync the gconf username, and we need to implement a sync of the encrypted keyring blob. Well, refining that a bit, we do store the flickr username on online.gnome.org already; but the way it's done seems a little mugshot-oriented and maybe doesn't make sense for o.g.o. Not sure. > h) > Another canvas library (yes Its staticly built, and yes I am also > guilty of using another canvas lib - goocanvas) but how is the gtk > canvas unification/blessing process going?. As an aside I guess this > becomes a non-issue if d is solved This is a huge intractable problem, see related to gtk-devel threads. I won't try to solve it ;-) I will note that the HippoCanvas is IMO different in what it's optimized for, vs. something like GooCanvas. See the gtk-devel threads. Havoc _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
