On 06/11/13 18:31, Sebastien Bacher wrote: > Le 06/11/2013 07:46, Tim a écrit : >>> We are still looking at updating the patches to have a build of the new >>> version to test (that works is going to be useful, even if that's not >>> this cycle). Then we expect to have some theming issues to resolve (as >>> usual with recent GTK update). Once those are resolved we can give some >>> testing to the new version and see what are the costs/benefits of the update >> I believe its mainly just the custom menu hack that needs updating? > > I guess that's the main one yes (out of themes issues) > >> Big +1 for this, however the changes also affect gnome-desktop3, which now >> depends on mutter for display config and idle manager. Maybe that >> needs to be forked as well? > Having a forked library is trickier, what happens to rdepends? (e.g nautilus, > with what lib do we build it? do we need to have another > nautilus build to use the other library?). I need to look into that one and > see if we can fold the different APIs in the same library (or > update and keep a compat API for non gnome-shell users) I have looked into this (i.e. non-forking option), the idle monitor stuff is straight forward and can easily be patched back dependent on Unity environment, but the display config stuff is quite disruptive, so the only option here is to implement the same dbus API in Unity (which itself can probably be mostly a straight forward cut+paste of code from mutter into Unity I guess) > >> I thought the GtkHeader was introduced in gtk 3.10, does that mean some apps >> have just gone and mimicked the look, without using the proper >> gtk API? > We looked a bit and what GTK 3.10 update would imply. It's likely that if we > get the new GTK some people are wanting to update some of the > apps, which makes us hit that issue... > >> from Ubuntu GNOME perspective we would like to see >> >> - update cogl/clutter to atleast 1.16, or preferably 1.18 > > I've no real opinion on cogl/clutter, I guess it's up to the Ubuntu GNOME to > decide on that one (assuming that there is no new depends > involved that would impact apps under Unity) I think its a fairly straight forward transition, still working through this however. > >> - update to BlueZ 5 > > That's not going to happen this cycle. The new bluez is incompatible with the > old one and not co-installable. The only desktop ported is GNOME > 3.10, and there has known regressions there (e.g DUN support not working) Right, haven't really looked at this too much, but well aware of the incompatibilities. > > > Cheers, > Sebastien Bacher >
-- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
