Port to GTK3 and PyGI

Thank you for opening this, much obliged :)

Looks like we could temporarily use https://live.gnome.org/PyGObject/IntrospectionPorting
They have pygtkcompat (apparantly allows PyGTK to be run on top of PyGI)

Looks a bit of a hack though. Combining PyGTK and PyGI normally produces instant segfault ^^

This script apparantly does most of the work of porting from PyGTK to PyGI: http://git.gnome.org/browse/pygobject/tree/pygi-convert.sh

Essentially does sed to replace all of the old names with new ones (gtk.* Gtk.*, etc.)

Because everything with gnome-panel moved to libpanelapplet via GIR, the only way of getting it to work
in Gnome Fallback is by first going to PyGI.

Look easy? :)

Correction: libpanel-applet-4

Nice, I will try that converter script tomorrow.

Luckily a lot of Cardapio's GUI-related code has already been pulled into a separate file (CardapioGtkView.py). The little GUI code that is left in Cardapio.py is currently marked with the comment "#TODO MVC" (although I may have missed some areas).

So how about I start out by working on those TODOs, and you start by porting CardapioGtkView.py into CardapioGtk3View.py?

I can open a new Cardapio branch for this soon, and give you permissions to contribute to it.

PS: No, it does not look particularly easy :) But it's the way Cardapio has to go anyways...

Ok I'm happy to do that. I think the main overall pain will be working out exactly how the new
panel applet API behaves. Thankfully we can separate them into Gnome 2 and Gnome 3
servers respectively (Bonobo/DBUS)

I'm sure I'll have CardapioGtk3View.py done tomorrow :)

From Cardapio's side of the code, writing a new applet is very straight forward. As you suggest, Cardapio applets are already separated into different files. So all different types of panel applets can coexist in the same codebase.

I think the more problematic side will be the Gnome side (as in, figuring out how to write applets for Gnome3's classic panel).

Not to mention fixing the TODOs that I mentioned before. That may take a while, since it may require rethinking some parts of the Cardapio code design. We'll see...

In fairness I have a good perspective on how gnome-panel works right now, I've patched it back to
how it used to be in terms of behaviour. I'm certain a lot of projects will adopt our patches and
Gnome will "be back". So it makes sense to start porting the main players now.

I'll check the docs and let you know of any wierdness or total api borkage I find.

More fun and games- we can't use *any* static imports. Even glib, etc, have to
all be converted to use GObject stuff.

Started on CardapioGtk3View.py: https://github.com/SolusOS/cardapio/blob/master/src/CardapioGtk3View.py

Looks like I'll have to make a Cardapio3.py before I can even test any of it.

Nope was wrong, we can mix but not gtk and pygi gtk

Ah, good. Otherwise, this transition would be near impossible!

Ikey, I just added you to Cardapio-Team. So now we can now work on this in the team-official branch below:

lp:~cardapio-team/cardapio/cardapio-gtk3

Also, it turns out that the TODOs I talked about earlier were in pretty good shape already, so I didn't have to touch much of the code to get that part done.

So how about you upload CardapioGtk3View.py to that branch when it's in an OK state and I'll try to integrate it into the Cardapio code? That is, I'll make the Gtk3 version have its own executable script, I'll edit Cardapio.py to pick the correct version of the View file depending on the executable, and so on.

And if you're running into any problems with the conversion, let me know. It seems you were left with the hardest part of the work, so maybe you'd like to split it. Up to you.

Syntax actually looks fine in most of the original file.

I think the main thing right now is getting the main Cardapio window to show
using PyGI itself, then we know we're in a fit position to rewrite the rest of it.

Regarding the panel-applet cruft, I believe for now we'll leave that untouched.
I'm working on a compatability layer that will hopefully enable Gnome 2 applets
to run as-is on Gnome 3 panel

It's a cheap solution. Basically we replicate the functionality of gnomeapplet.*
python binding by passing all calls back and forth to the new PanelApplet
GIR binding. https://github.com/SolusOS/gnome2-compat

With our work on porting Cardapio and my new compatability layer I think
the future looks very bright for Gnome :)

Pushing some commits tomorrow :)

Great!

--

*Thiago Teixeira*http://thiagot.com

On Mon, Jun 4, 2012 at 11:12 AM, Ikey Doherty <email address hidden>wrote:

> Pushing some commits tomorrow :)
>
> --
> You received this bug notification because you are a member of Cardapio
> team, which is the registrant for Cardapio.
> https://bugs.launchpad.net/bugs/1005259
>
> Title:
> Port to GTK3 and PyGI
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cardapio/+bug/1005259/+subscriptions
>

Apologies for taking so long. Still trying to port to PyGI! :/
That aside, I still haven't worked out how to push to launchpad lol.
So, I thought I'd contribute the changes I have made.

https://github.com/SolusOS/cardapio-gnome3
A Working Gnome 3 Applet for Cardapio :)

https://github.com/SolusOS/Cardapio
My slightly modified Cardapio (extra signal + method, cardapio-gnome3 as recommendation)

Relevant commits to Cardapio:
https://github.com/SolusOS/Cardapio/commit/d34f54f9eb99c6a576dee25dc353aced5885bd4f
Added dbus method for determining whether the menu is visible

https://github.com/SolusOS/Cardapio/commit/e48f96da557159739f46598b28e317e8e2798579
Added signal, on_menu_visibility_changed

The gnome 3 applet doesn't yet know about orientation and it isn't dynamically updated from
the Cardapio configuration. I think that will require adding a new DBUS signal to Cardapio itself,
on_configuration_changed. Then the cardapio-gnome3 applet would pull the configuration and
update as needed.

As you can see I Made the SolusOS.png logo default in our implementation, but I'm happy to revert
that :)

Oh. Nearly forgot the screenshot! :)
http://ompldr.org/vZTliOA

I believe I used a slightly older version of Cardapio :S
Well, you can see what signals it needs anyway ^^

I've rebased provided patches to latest Cardapio.
They are on their way to main tree and eventually to packages repository.
Stay tuned.

@Eugene Sam: I'm still "fixing" it and I'll get them totally fixed up so
that the Cardapio gnome classic applet can be considered first-class
It's a massive hit in SolusOS :)

Apologies Eugene San I spelt your name wrong >_<

Worked out how to resolve the issue with the keybinding popping the menu up in the middle of the screen
I'll paste a patch here soon.
Basically we just use gobject's idle queue to check every few hundred miliseconds the location of the
applet on the screen. No real way of knowing where you are through the PanelApplet library, but as
you can see the click handler finds out where it is.
Now if this is constantly refreshed then we can do a dbus call to set the default location of Cardapio
and it will always appear in the right place regardless of where you moved the applet to.

Things to add (by me):
* Applet orientation code (should render in the right direction)
* Patch discussed above
* Make the Cardapio preferences show the Applet options for this particular applet (only blacklist awn,
otherwise always show it)
* Improve Cardapio's category switching (hovering over a button switches category instantly, should have
some form of delay to blank accidental hovers, improves usability)
* A menu tooltip :)
* *possibly* a new About Cardapio item on the menu applet button. Personally I'm not too keen on using
   such entries as it breaks consistency with Gnome Classic desktop but I'm all for advertising my name :P

@ikey-doherty: Thank you for your dedication to the project.
We are keen to see your new patches.
Note that by now your previous modifications are now in lp:cardapio tree.
It would be really nice if you could provide future modifications against that tree, in order to ease integration.
Thanks.

@Eugene San: No worries. SolusOS uses Cardapio in 1 and 2, and with great pride.
What's the point in priding yourself on a main component if you're not going to
contribute to it?
Far too many projects just use instead of improve, way I see it, we're just saving
duplication and fragmentation by keeping it at the core :)

I'll rebase our packages to use latest lp:cardapio and push patches against it