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.
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.
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 :)
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.
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 :)
@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 :)
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
Thank you for opening this, much obliged :)
Looks like we could temporarily use https:/ /live.gnome. org/PyGObject/ IntrospectionPo rting
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? :)