Of note, there have not been any releases of gtk-sharp corresponding to gtk+.  Even if a release happens soon, we can't count on anybody to have it in older distros.  Will probably need something like

#if HAVE_GTK_SHARP_214
Gtk.Uri.Show (...)
#else
gtk_uri_show(...)
#endif


#if !HAVE_GTK_SHARP_214
[DllImport(gtk...)]
internal static void gtk_uri_show(...);
#endif

I'll talk to Mike about timeframes for gtk-sharp 2.14.x.  Patches welcome on this.

Either way, we need to bump our gtk+ dependency to 2.14 now.

ifdef'ing is totally fine.

> I'll talk to Mike about timeframes for gtk-sharp 2.14.x.  Patches welcome on
> this.

Also see http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00439.html . Something like --enable-deprecated-bindings for gtk-sharp might be nice too, so C# GTK developers do realize that they use deprecated API and should update their codebase.

I don't see the point of this mail in comment 2: gtk-sharp already comes with support for [Obsolete] attributes, which generate compile-time warnings for deprecated stuff. One of our (tomboy's) open bugs is about compiler warnings and targets deprecation warnings as well.

The main problem for this is currently the supported baseline: As long as we're supporting gtk 2.10 we're unable to fix a lot of deprecation warnings without huge amounts of ifdefs (which would suck and make the source ugly). As soon as we bump the requirements we can resolve these warnings.

Bottom line: No need for "--enable-deprecated-bindings" as far as I understand it.

> One of our (tomboy's) open bugs is about compiler warnings
and targets deprecation warnings as well.

And that would be bug #569890

Looking back at distros I want to support, I would rather make us depend on gtk+ 2.12, with conditional support for 2.14.

Is this on the list for the next weeks (to get it done for 2.28)?

(In reply to comment #6)
> Is this on the list for the next weeks (to get it done for 2.28)?
> 

Yes, which is why the target milestone is set to 0.15.x.

Turns out gtk-sharp-beans project already had a binding for this, and since there won't be a new non-2.12 gtk-sharp until after gtk+ 3.0, have decided to borrow the code from gtk-sharp-beans.

Fixed in master.

Hope I don't make a fool out of myself, but... Aren't Gnome.Program and Gnome.Client in Tomboy/GnomeApplication.cs also libgnome|ui-usage. At least there equivalents in C are.

(In reply to comment #9)
> Hope I don't make a fool out of myself, but... Aren't Gnome.Program and
> Gnome.Client in Tomboy/GnomeApplication.cs also libgnome|ui-usage. At least
> there equivalents in C are.

I'm not entirely sure.  I am finding the wiki page a bit confusing.  Some things are marked DONE, implying that they are deprecated, and others are marked TODO, implying that they are not deprecated.  Lots of Gnome.Program and Gnome.Client stuff is still marked TODO.  But maybe I'm misunderstanding.  Here's the API we use, would love for somebody to just tell me what's deprecated and what's not so I can avoid spending time researching this:

program = new Gnome.Program (display_name, Defines.VERSION, Gnome.Modules.UI, args);

// Register handler for saving session when logging out of Gnome
Gnome.Client client = Gnome.Global.MasterClient ();
client.SaveYourself += OnSaveYourself;



// Restart if we are running when the session ends or at crash...
Gnome.Client client = Gnome.Global.MasterClient ();
client.RestartStyle =
        Gnome.RestartStyle.IfRunning | Gnome.RestartStyle.Immediately;
client.Die += OnSessionManagerDie;



client.SetRestartCommand (restart_args.Length, restart_args);

Well I guess the plan for 3.0 is that all libgnome|ui usage should go, but maybe André could clarify on this a bit...

(In reply to comment #10)
> I'm not entirely sure.  I am finding the wiki page a bit confusing.  Some
> things are marked DONE, implying that they are deprecated, and others are
> marked TODO, implying that they are not deprecated.

Everything is deprecated. And the page is of course outdated, no matter how many times I ask developers to update that page...

(In reply to comment #11)
> Well I guess the plan for 3.0 is that all libgnome|ui usage should go, but
> maybe André could clarify on this a bit...

Yes, that is the plan.

Thanks, it's a lot more clear to me now.  Reopening bug.

Setting GNOME target to 2.28 (though fixing it for 2.29.1 is also fine and maybe even more safe, now that we are late in the 2.27.x cycle).

(In reply to comment #14)
> Setting GNOME target to 2.28 (though fixing it for 2.29.1 is also fine and
> maybe even more safe, now that we are late in the 2.27.x cycle).

Yes, it may get pushed to next cycle, just because of the work involved in properly binding and using EggSmClient.  We'll see.  :-)

Next cycle for the rest of libgnome.  If anyone wants to jump in here with a patch or C# bindings for EggSmClient, that would be very welcome.

Has there been any progress for GNOME 2.30 coming closer? I assume not...

No progress yet, still targeted for this cycle.

Only guessing, but maybe you can drop Gnome.Program and Gnome.Client and not use EggSmClient.
Is really session management a required feature for you?

Read Havoc's comment about this here: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c30

All we need to do is to be able to save notes before exiting.  I'll have to do some testing to see if we can really do that without access to session events.  We already connect to SIGTERM and SIGINT, so maybe we're okay...

I'm working on this now.  I intend to follow Havoc's suggestion in https://bugzilla.gnome.org/show_bug.cgi?id=79285#c14 .

Basically, whenever (non-applet) Tomboy runs it will put its .desktop file in the autostart dir.  If the user explicitly quits Tomboy (as opposed to having the session quit it on log out), we'll remove the file from the autostart dir.

There is a nice API for the .desktop files in GnomeDesktopItem.  Anyone know if this is also considered obsolete?

Okay, looking into this we still have the issue of being notified when Tomboy quits, so we can save unsaved notes.  I thought that there must be a unixy exit signal I could catch when Tomboy was killed during logout, but I am not seeing it.

(In reply to comment #21)
> There is a nice API for the .desktop files in GnomeDesktopItem.  Anyone know if
> this is also considered obsolete?

gnome-desktop will stay for GNOME 3.

(In reply to comment #23)
> (In reply to comment #21)
> > There is a nice API for the .desktop files in GnomeDesktopItem.  Anyone know if
> > this is also considered obsolete?
> 
> gnome-desktop will stay for GNOME 3.

Okay, great. :-)

So the only issue left to figure out is how to make sure we get notified before we're killed at logout, so we can save notes.

Should be able to do this for next dev release.  Patches, as ever, are welcome.

Isn't the gnome-session DBus API enough?

http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager::SessionOver

I do not know how much time you have to save when the SessionOver signal is sent though.

(In reply to comment #25)
> Isn't the gnome-session DBus API enough?

It had better be, because it's all we get.  :-)

Unfortunately this has been bumped to next cycle.

Created attachment 162602 [details] [review]
Use Gnome Session DBus API for session management

Here's an initial patch with the gnome-session bindings. This requires DBus which I haven't added the configure script yet.

With this patch, when we get the Query/EndSession signal, we just return OK when we really should save the notes first. Also, even after getting the EndSession, it's possible we would want to respond to the CancelEndSession signal by resuming normal operations. In order to accomplish these, we would need to split up the ExitingEvents into  "SaveState" events and true ExitingEvents. The former does all the state saving but we can still continue running while the latter would be we're really done and there's no turning back. Although, it might be possible to stick the re-initialization code into the cancel callback.

Also, Sandy, you mentioned you added the dropping/cleanup of the .desktop file but I didn't see this in the code. This will be required for handling of the Restart Action.

Comments/feedback appreciated.

Aaron, thanks for this patch!  I'm looking forward to testing it out.  I tried to do this myself but found the spec confusing enough that I couldn't quite get it to work.  I really appreciate you putting the time in. :-)

Tomboy already requires ndesk-dbus by default, so don't worry about that.  With this change I think we're going to have to make it a hard requirement and no longer optional.  Otherwise, users could lose notes with a simple logout.

I did not actually do anything with the dropping/cleanup of the .desktop file yet.  But it should be easy to do.

I'll try to get to this patch before Monday's release.

Aaron, your patch is working great!  I'm cleaning it up to comply with our style guidelines before I commit/push.

Would you mind if I license GnomeSession.cs as MIT/X11 instead of LGPL so that it can be easily copied by other apps?

(In reply to comment #29)
> Aaron, your patch is working great!  I'm cleaning it up to comply with our
> style guidelines before I commit/push.
Great to hear.

> Would you mind if I license GnomeSession.cs as MIT/X11 instead of LGPL so that
> it can be easily copied by other apps?
Sure, using the MIT/X11 license is fine.

Is there anything left to do to remove the libgnome dependency? Do you want to open a new bug for handling the .desktop file in gnome?

Here are the notes I've made to myself regarding remaining issues in your patch and other libgnome obsolescence:

 * Need to write .desktop mangling code
   - Possibly get rid of RegisterSessionManagerRestart completely
 * Need to get rid of Gnome.Program, right?
 * startup_id not used, is envar usable? Need to test
   - Is "Tomboy" important, vs "tomboy"?
   - If getting rid of Gnome.Program, re-appropriate display_name for startup_id
 * Lots of strings should be constants

I was planning to work on them tomorrow or Monday before release.  If you'd like to work on any of it let me know.  I'll attach my version of your patch in a minute.

Created attachment 162844 [details] [review]
Use GNOME Session d-bus API instead of Gnome.Client for session management

This is part of the cleanup to remove usage of obsolete libgnome APIs.

I'm just about done with this, and it will be in Monday's release (possibly without the .desktop file stuff, which would be a minor regression).

The only problem left is that gnome_program_init seemed to initialize bonobo for me, and now I need to do it myself when running as an applet.  I just need to figure out the most appropriate way to do that and then I'll push this.

Please, consider using the new DBUS based gnome-panel api so you do not need to use bonobo:

http://live.gnome.org/GnomeGoals/AppletsDbusMigration

(In reply to comment #34)
> Please, consider using the new DBUS based gnome-panel api so you do not need to
> use bonobo:
> 
> http://live.gnome.org/GnomeGoals/AppletsDbusMigration

I need to support versions of gnome-panel older than 3.0, so it looks like I'm going to need to use some conditional compilation here.

Javier, please file a new bug regarding the new gnome-panel API if you get a chance.

(In reply to comment #33)
> The only problem left is that gnome_program_init seemed to initialize bonobo
> for me, and now I need to do it myself when running as an applet.  I just need
> to figure out the most appropriate way to do that and then I'll push this.

For anyone else who runs into this (as if anyone other than Tomboy is using the C# panel applet bindings), the issue is that C applets all use a handy dandy macro PANEL_APPLET_BONOBO_FACTORY which calls (among other things) bonobo_init, gtk_init, and panel_applet_factory_main.  The C# binding method PanelAppletFactory.Register *only* calls panel_applet_factory_main, probably because every example ever used Gnome.Program which caused things like bonobo to be initialized.

Calling bonobo_init from C# is messy and I'm not done yet, but I thought I'd at least describe the issue so it's documented somewhere.

It's conceivable that I might push the d-bus session patch without removing use of Gnome.Program for today's release.

Maybe this is not helpful as it's C# instead of C, but the code for gnome-applets ported to D-Bus is located at http://cgit.freedesktop.org/~carlosgc/gnome-applets/log/?h=libpanel-applet-dbus

Thanks Andre, I've been reading that. :-)

I'll handle the bonobo->dbus migration in a different bug, though.

(In reply to comment #35)
> Javier, please file a new bug regarding the new gnome-panel API if you get a
> chance.

Filled bug #620829

Comment on attachment 162844 [details] [review]
Use GNOME Session d-bus API instead of Gnome.Client for session management

I committed my version of this patch, but have not yet removed the use of Gnome.Program, as I'm having trouble getting the panel applet to continue working without it.

(In reply to comment #40)
> (From update of attachment 162844 [details] [review])
> I committed my version of this patch, but have not yet removed the use of
> Gnome.Program, as I'm having trouble getting the panel applet to continue
> working without it.

I can take a look at this and the .desktop work.

Here is a dump of the sort of thing I was trying, but my bonobo_init calls kept failing, or they would work but then Tomboy would start without an icon in the panel, and it would crash after a couple of minutes.  Also, I had to occasionally restart the panel.

http://armstrong-clan.net/dump/manual_bonobo_usage.diff

Okay, I pushed some work from bug #603423 to disable the panel applet by default.  Since we only need Gnome.Program as a work-around for initializing libbonobo, that means we can also disable that code by default and completely stop depending on libgnome (at least, gnome-sharp and gnome-desktop-sharp).

As soon as we can (or as soon as we get a patch), we'll port the applet to the new d-bus API (bug #620829).  But until then, disabling it by default is the best I can do to kill this bug.

Relevant commits:

http://git.gnome.org/browse/tomboy/commit/?id=48c4e7b2dd577839ed040aada114efa331baa431

http://git.gnome.org/browse/tomboy/commit/?id=72fdf8afac18694233ba9506512aea7c2958734c

Next on the list is gconf->gsettings, but I'm pretty sure that's not part of this bug.  If I'm missing anything please feel free to re-open.

Aaron, I'd still appreciate any help on the .desktop stuff (and even a different libbonoboinit workaround) if you feel like doing more hacking.  And thanks again for all your work on this bug!

I've been digging through the bindings to figure out what bonobo call we're missing but no luck. After enabling ORBit2 debugging, I can see that the TomboyApplet object is not being created by when registering with the PanelAppletFactory but don't understand how those calls map back to bonobo.

At this point I think you're right, it makes sense to just drop it and move forward with the DBus API. I'll work on the .desktop handling first.

Created attachment 164903 [details] [review]
Manage the .desktop file placement in the gnome autostart directory

Here's the support for the .desktop file. Tested in the default build and with the legacy --enable-panel-applet build. We'll only drop the .desktop file when running in non-panel mode.

Review of attachment 164903 [details] [review]:

This looks good to me.  A few points:
* The autostart file should not include --search, which the default .desktop does
* Need to see if this API requires a specific version of gnome-desktop-sharp, in which case we'd need to modify the check in configure.in
* gnome-desktop-sharp may still contain or reference deprecated API, so we may need to bundle the desktop file API directly in Tomboy. I'll look into this
* The opening { in each block should not be on its own line, it should be on the same link as the if/for/whatever, preceded by a space

Thanks for testing with and without the panel applet.  As soon as the above points are resolved I'll push this for our next release.

(In reply to comment #46)
> Review of attachment 164903 [details] [review]:
> 
> This looks good to me.  A few points:
> * The autostart file should not include --search, which the default .desktop
> does
> * Need to see if this API requires a specific version of gnome-desktop-sharp,
> in which case we'd need to modify the check in configure.in
> * gnome-desktop-sharp may still contain or reference deprecated API, so we may
> need to bundle the desktop file API directly in Tomboy. I'll look into this
> * The opening { in each block should not be on its own line, it should be on
> the same link as the if/for/whatever, preceded by a space
> 
> Thanks for testing with and without the panel applet.  As soon as the above
> points are resolved I'll push this for our next release.

Fixed. What's the best way to go about figuring out the required lib version? Should I just look through their git logs looking for gnome-desktop-item.h changes?

Created attachment 164942 [details] [review]
Manage autostart desktop entry

Review of attachment 164942 [details] [review]:

Sorry, a couple of other things occurred to me when looking over the new patch.  See below.

As for your question about checking the lib version, don't worry about that, I'll take care of it when I decide whether or not to just bundle this class from gnome-desktop-sharp directly in Tomboy.

::: Tomboy/GnomeApplication.cs
@@ +90,3 @@
+			Gnome.DesktopItem desktop_item = null;
+			string autostart_dir = Path.Combine (XdgBaseDirectorySpec.GetUserDirectory ("XDG_CONFIG_HOME", ".config"), "autostart");
+			string share_paths = XdgBaseDirectorySpec.GetUserDirectory ("XDG_DATA_DIRS", Path.Combine ("usr",Path.Combine ("local", "share")) + Path.PathSeparator + Path.Combine ("usr","share"));

I believe that should be "/usr", not "usr".

@@ +133,3 @@
+		private void RemoveAutostartDesktopItem ()
+		{
+			string autostart_file = Path.Combine (Path.Combine (XdgBaseDirectorySpec.GetUserDirectory ("XDG_CONFIG_HOME", ".config"), "autostart"), "tomboy.desktop");

Probably better to only look up this path once.

Created attachment 165031 [details] [review]
Manage the manage gnome autostart

* Use absolute paths for XDG fallback
* Only lookup XDG paths once

Looks good.  I'll push as soon as I figure out the gnome-desktop-sharp stuff I mentioned earlier.  Thanks again for your help!

The Desktop File API is going away.  See http://mail.gnome.org/archives/desktop-devel-list/2010-July/msg00025.html

Let's just change the Exec string with a bit of file IO and totally drop this dependency.

Sorry for the churn.  I can make this update before the next release if you don't have time.

Okay. You're talking about the release on July 12th? I can take on this work.

(In reply to comment #53)
> Okay. You're talking about the release on July 12th?

Yup.

> I can take on this work.

Sweet, thanks!

Created attachment 165369 [details] [review]
Manage the autostart desktop file without gnome-desktop