Dear all,
The uTouch stack[1] from Canonical is a requirement for my packaging around the Indicators and Unity. I've taken a peek at [1] and decided to package the rest, as it looks interesting. This raises some questions in which I seek advice:
1. gtk+-2.0 - Canonical's gtk2 package[2] seems heavilly modified. Current patches[3], and for Natty is comes in 2.23.90. Currently I'm forced to use 1 patch [4] to satisfy libindicate (requirement for indicators and unity), and 2 more patches [5] and [6] (gdk-pixbuff) for 'proper' generation of gobject-introspection stuff. What would be the way to proceed here? Any guidance/help would be fine to select the patches we really require. Thanks to Dimstar for helping with patches [5] and [6].
2. Unity requires compiz. Unfortunatly for us, this comes with 'glib mainloop patch'[7]. I'm finishing building the required packages. At some point soon everything aims this will be a part of compiz. Unity plugin is to be enabled from CCSM. For now I will be doubling the packages. Adam Williamson from Fedora made a couple of blog posts around this [8], [9].
3. Though I can package the Multitouch software from Canonical, I have no idea on how integrating it... It may be interesting for some. If anyone wants to provide feedback and really test this software, any feedback would be welcome. Feel free to contact me on private or use this list, all works for me.
4. KDE - The indicators at least are prepared to integrate with KDE. If anyone can point documentation on KDE packaging or a couple of standard examples on OBS, will be most welcomed. I've noticed there's already a libindicate-qt laying around. I am already doing some modifications for GTK3, this would probably be also the moment to add the stuff for KDE. I don't really see a reason to cut out KDE users, so this will happen soon.
5. Updates - Canonical updated loads of software. Currently it's broken due to patching required for proper generation of Vala CLI/Gir files. Now here's the deal... I can turn off introspection, but python modular stuff will be utterly broken, and this is bad. I'm currently rechecking the patches applied on Ubuntu on GTK and the tables os symbols to check for missing stuff, hopefully this will sort my issues.
6. Distribution of contents - Vincent asked me the other day if I wanted to push this to Factory. My personal standing on this (as I told Vincent) is that I would prefer to have GNOME:Ayatana as a separate repository so users can do a 'zypper dup' (I will provide the necessary documentation on this covering YaST2 and zypper). The reason why I think this is better is tightly related to the high level of patching required in many things, specially GTK2, I haven't even started to look on GTK3. I would like to know people's opinion on this as well... should I start looking and documenting the stuff that is 'touched' by Canonical and pass on the word so we can support some of their patching on upstream projects? I really don't have much clues on how this 'upstream - downstream' processes usually are. Everything around this is pretty much new to me in all aspects. Any advice?
7. Marketing - I have my own ways to bump this into the audience without requiring intervention from the Marketing Team. I believe I've made already enough fuss around this, and given the present circunstances around GNOME3, I find it a better choice not to engage on agressive marketing promoting this project until GNOME3 is established on the Community, nevertheless, I find it interesting to provide a minimum marketing embracing the concern that it doesn't endanger the deployment and spot light of GNOME3 and gnome-shell. Any advices on this?
8. Broken packages - Currently some (if not a lot) of packages are broken until I fix GTK2. As you all know, I'm not very experienced with this (gtk2 and gobject-introspection), so this might take a couple of days till I checkout all the patches on a 'test/trial/error' basis. Should be fixed as soon as possible.
9. Unity - Unity (without the indicators) shouldn't bring much problems, and by default if the indicators aren't present it will use the default gnome applets. Since Unity relies on 3 libraries to build (bamf, nux and dee, which are already packaged), on compiz (which should be mainstreamed soon), this is most likely something we could included on Factory as an option. Whats your opinion on this? Should we include Unity and ignore the indicators for Factory? (indicators will require a near flawless gobject-introspection solution).
Sorry for the wall of text.
NM
[1] - https://launchpad.net/canonical-multitouch [2] - https://launchpad.net/ubuntu/+source/gtk+2.0/2.23.90-0ubuntu4 [3] - https://launchpad.net/ubuntu/+archive/primary/+files/gtk%2B2.0_2.23.90-0ubun... [4] - http://tinyurl.com/4923qwk [5] - http://tinyurl.com/49cdxfb [6] - On gdk-pixbuf - http://tinyurl.com/4hpsy3z [7] - http://git.compiz.org/~dbo/compiz-with-glib-mainloop/log/?h=master&=swit... [8] - http://www.happyassassin.net/2010/12/03/unity-on-fedora-possibly/ [9] - http://www.happyassassin.net/2011/01/15/compiz-0-9-for-rawhide-fedora-15-tes...
On Tue, 2011-01-18 at 20:21 +0000, Nelson Marques wrote:
- gtk+-2.0 - Canonical's gtk2 package[2] seems heavilly modified.
Current patches[3], and for Natty is comes in 2.23.90. Currently I'm forced to use 1 patch [4] to satisfy libindicate (requirement for indicators and unity), and 2 more patches [5] and [6] (gdk-pixbuff) for 'proper' generation of gobject-introspection stuff. What would be the way to proceed here? Any guidance/help would be fine to select the patches we really require. Thanks to Dimstar for helping with patches [5] and [6].
I took a quick look at the patches and most seem to be backports from upstream. If they are, it should be easy to put them into our own gtk2 package. If some are not upstream, I'd be interested in knowing why ;)
Do you know why libindicate needs that ubuntu_gtk_widget_set_has_grab() patch? That function seems quite odd; it looks like they are trying to work around some of GTK+'s behavior in a weird way.
Federico
On Wed, Jan 19, 2011 at 12:14 AM, Federico Mena Quintero federico@novell.com wrote:
On Tue, 2011-01-18 at 20:21 +0000, Nelson Marques wrote:
- gtk+-2.0 - Canonical's gtk2 package[2] seems heavilly modified.
Current patches[3], and for Natty is comes in 2.23.90. Currently I'm forced to use 1 patch [4] to satisfy libindicate (requirement for indicators and unity), and 2 more patches [5] and [6] (gdk-pixbuff) for 'proper' generation of gobject-introspection stuff. What would be the way to proceed here? Any guidance/help would be fine to select the patches we really require. Thanks to Dimstar for helping with patches [5] and [6].
I took a quick look at the patches and most seem to be backports from upstream. If they are, it should be easy to put them into our own gtk2 package. If some are not upstream, I'd be interested in knowing why ;)
Do you know why libindicate needs that ubuntu_gtk_widget_set_has_grab() patch? That function seems quite odd; it looks like they are trying to work around some of GTK+'s behavior in a weird way.
Federico,
I apologize, it's not libindicate, it's ido (libido) which requires that symbol to be present on GTK. As far as I am aware it's used to grab widgets and bars for the indicators to work.
NM
Federico
On Wed, 2011-01-19 at 21:12 +0000, Nelson Marques wrote:
I apologize, it's not libindicate, it's ido (libido) which requires that symbol to be present on GTK. As far as I am aware it's used to grab widgets and bars for the indicators to work.
No problem. I checked the source for ido really quickly and talked to Cody Russell.
They use that function in the widget that does menu items with a slider inside them. Normally pressing a mouse button on a slider makes it get a GTK+ grab, and this breaks the grab that the menu item had - thus closing the menu. They hack around this with that function.
Cody says that he doesn't have a good solution yet :)
I'm not wholly opposed to including that patch if that will make the Unity shell work; as long as that kind of hackery doesn't propagate to other programs... :)
Federico
<snip>
Cody says that he doesn't have a good solution yet :)
I'm not wholly opposed to including that patch if that will make the Unity shell work; as long as that kind of hackery doesn't propagate to other programs... :)
Federico,
I might have made a small confusion. I just checked real fast and ido is only used for some indicators. Unity doesn't require this patch, indicators do. If we want to make indicators to Factory, then we need this, if we want only Unity then we don't need this patch.
According to the documentation I've seen on Unity, if Indicators are present they can be used, if not it will fallback to GNOME's default bar applets (which is also nice, and Vincent told me they were kick ass on GNOME3).
Whatever decision you take, I'll support cause you're the man on GTK stuff :)
Once more, thanks for helping on this topics.
Nelson
Federico
-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Thu, 2011-01-20 at 19:50 +0000, Nelson Marques wrote:
I might have made a small confusion. I just checked real fast and ido is only used for some indicators. Unity doesn't require this patch, indicators do. If we want to make indicators to Factory, then we need this, if we want only Unity then we don't need this patch.
According to the documentation I've seen on Unity, if Indicators are present they can be used, if not it will fallback to GNOME's default bar applets (which is also nice, and Vincent told me they were kick ass on GNOME3).
OK, perfect. So we can do without this patch for now. Hmm, do you plan on submitreq'ing a gtk2 with some of those patches?
Federico
On Thu, Jan 20, 2011 at 9:00 PM, Federico Mena Quintero federico@novell.com wrote:
On Thu, 2011-01-20 at 19:50 +0000, Nelson Marques wrote:
I might have made a small confusion. I just checked real fast and ido is only used for some indicators. Unity doesn't require this patch, indicators do. If we want to make indicators to Factory, then we need this, if we want only Unity then we don't need this patch.
According to the documentation I've seen on Unity, if Indicators are present they can be used, if not it will fallback to GNOME's default bar applets (which is also nice, and Vincent told me they were kick ass on GNOME3).
OK, perfect. So we can do without this patch for now. Hmm, do you plan on submitreq'ing a gtk2 with some of those patches?
Federico,
Some patches are submitted upstream already. I'm working on the last patches GTK needs for the libappindicator to work properly (removes the menus from applications and displays them on the Unity top bar). Once I have all the functionality required, I'll compile a list of the patches required, check the information if they were submitted upstream and where/when/how and pass it on to you.
If it's of interest, the video on this article[1] shows unity and the top with using indicator-application (required libappindicator, appindicator-python and appindicator-sharp, already packaged).
[1] - http://www.linuxuser.co.uk/news/new-ubuntu-unity-video-trailer-released/
Sorry if sometimes I might not make sense, but my knowledge on this kind of technology and methodology is poor. This is the first time I'm trying something like this and never made nothing on this field. You have my word I will provide a summary on the end involving all required patches and my notes on them and pass it to you so you don't waste more time than needed.
Once more, thanks.
NM
Federico
-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
-
Federico Mena Quintero -
Nelson Marques