Mailinglist Archive: opensuse-gnome (56 mails)

[Nelson Marques <nmo.marques@xxxxxxxxx>]

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-0ubuntu4.debian.tar.gz
[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&=switch
[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-test-repo-up/
-- 
To unsubscribe, e-mail: opensuse-gnome+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx