Re: [Mono-dev] Mono 2.8 gnome-sharp not compiling...
On Sat, 2010-10-09 at 10:59 -0400, Miguel de Icaza wrote: Hello, We no longer ship Mono.GetOptions.dll, since this is a sample, you can just remove it from the Makefile. In the meantime, we should get the sample rewritten to use the new Mono.Options. It's been worked around in master since May to not build the sample if Mono.GetOptions isn't available. So it's just a matter of rolling a new release. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] where is gtk-sharp-2 ?
On Thu, 2009-12-10 at 14:32 -0500, ptr wrote: hey all I am trying to setup a mono parallel enviroment according to http://www.mono-project.com/Parallel_Mono_Environments Where is gtk-sharp-2 located ? I cannot find it under the anonymous trunk You most likely want branches/gtk-sharp-2-12-branch. trunk/gtk-sharp is unstable, will target the gtk 3.0 api, and has no current release plans. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] where is gtk-sharp-2 ?
On Thu, 2009-12-10 at 14:48 -0800, ptr2009 wrote: Hey Mike Are you saying I only need gtk-sharp-2-12-branch. The parallel mono environment documentation seems to refer to both gtk-sharp gtk-sharp2. I am trying to build a parallel mono 2.6 environment. Oh dear, sounds like that page needs some love. The instructions are based on mono-1.1, which had parallel gtk-sharp 1.x and 2.x installs. I'm not aware of any software that still requires gtk-sharp 1.x. A gtk-sharp-2.12 install should satisfy all your needs. Also is monodoc merged with main trunk now ? Yes, I believe all the docs and tools were merged into mcs trunk. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Some questions in regards to the GTK# API
On Sun, 2009-11-29 at 19:27 +0100, Claus Jørgensen wrote: I made a example of what I think could be nice to have here: http://windcapes.pastebin.com/m7f2f591b , but I'm wondering if there is there a reason for them not being there, seeing that a number of other properties are available, but not these. There is already a DefaultSize property. If you want to add the others, feel free to open a bug and attach a patch. The file you want to modify is gtk/Window.custom. We can only add convenience API like this in unstable versions, though, which means it will only be available in 3.0 and beyond when development begins on that. Plus, I find it very strange that there is no parameter-less constructor for Gtk.Window class. After all, it's rather ugly having to call the base constructor when making a derived Window, which is rather typical for GUI development. I don't know how ugly it is. It would be extremely unusual to create a toplevel window without setting the title of the window, which is one available overloads. I'm not opposed to adding default constructors for everything. It would make things simpler MD's designer if all the widgets had default constructors for example. I'm not sure how feasible that is given the use of construct-only properties in gtk+. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gtk depends on Winforms ¿?
On Sat, 2009-09-05 at 09:15 +0200, Christian Hoff wrote: In Windows I use 'mkbundle' [1] We should probably put that code in a try-block. What do you think, Mike? My question would be, what do you do in the catch block? The winforms reflection thing is a huge hack, we know that, and the poster is tripping over it because of using mkbundle instead of depending on mono or .Net. We could also take the stance that if somebody wants to do this sort of minimal packaging, they are required to add an artificial ref to swf to ensure it gets bundled. But they won't have any clue that's required if we just silently fallback to unthemed windows when we can't find swf. According to Robert Jordan on this thread, it's a PeekMessage/GetMessage loop that's required to happen before the first handle is created. We should try a pinvoke solution like that and see if it works so we can remove the hack altogether instead of figuring out ways to make the hack more palatable. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Visual Profiler
We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles. I have created a Wiki page to track the feature capabilities and plans: http://mono-project.com/MonoVisualProfiler There is also now a Visual Profiler category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion should occur on mono-devel-list. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GTK# 2.12.9 installer breaks on upgrades
On Sun, 2009-05-31 at 22:54 +0200, Mirco Bauer wrote: Under software it lists GTK# 2.12.9 (no .8, thus I assume it upgraded). When removing GTK# 2.12.9 and installing it again, the assemblies are back in the GAC and the GTK# application runs again. I file a bugreport for this issue already here: https://bugzilla.novell.com/show_bug.cgi?id=508580 Thanks for the report. We've released a 2.12.9-2 installer at the usual place. Thanks for testing it as well. -- Mike Kestner mkest...@novell.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Installers
I am currently working to provide some additional installation capabilities to support the porting of MD to windows. This includes shipping libraries like Mono.Posix, Mono.GetOptions, SharpZipLib, and Mono.Addins. We've previously received requests to include Mono.Posix in the Gtk# for .net installer, as projects designed with the stetic designer in MD generally contain a Catalog dependency for string translation. The Gtk# installer already ships Mono.Cairo. The above examples indicate that many gtk-sharp applications will likely contain dependencies drilling down into the mono stack. Tomboy uses mono-addins. MD uses several mono libs. My inclination is to just merge these additional libraries needed by MD into the current installer, as opposed to maintaining a separate installer which applications will need to add to their deployment instructions. The current Gtk# for .Net installer weighs in at around 8MB. These additional libraries currently take up just under 1MB in a standalone installer, so the addition of them to the current installer is roughly a 12% increase in download size. I think the user convenience of being able to download all the mono stack goodness in one installer outweighs any advantage to be obtained by carving out subsets of the stack into independent installers. It's conceivable we could add additional libraries from the stack in the future if the demand is high. Thus, my proposal is that we move to a single Mono Libraries for .Net installer which contains these mono stack libraries, including Gtk#. I believe I would probably name the installer mono-libraries.msi and version it with the major/minor version number of the mono release, and an installer version to support updating gtk-sharp and mono-addins and other libraries we might add which don't conform to the mono release schedule. We can probably head off any potential issues related to the disappearance of the Gtk# for .net installer by providing some more detailed information about the contents of the installer on the Downloads page, but there may be some inertia out there around the existing installer name on some application download sites, ie Download the latest version of the Gtk# for .Net installer from the mono project downloads page. Feedback appreciated. In particular I'd like to hear from those of you using the current Gtk# for .net installer or those considering win32 ports in the future. Which would you prefer, one installer or two? If one, should it remain the Gtk# for .net installer for historical purposes, even containing the infusion of mono tastiness, or do we rename it to Mono Libraries for .Net? -- Mike Kestner mkest...@novell.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Usage of construct properties in a wrapped GObject library
On Mon, 2009-04-27 at 11:42 -0700, MardyTardi wrote:
=
public Map () : base (IntPtr.Zero)
{
if (GetType () != typeof (Map)) {
CreateNativeObject (new string [0], new GLib.Value[0]);
return;
}
Raw = osm_gps_map_new();
}
=
osm_gps_map_new() is the C constructor of my GObject, but what I'd like to
have is a constructor which accepts a list of properties + values, and pass
it to g_object_newv(). But I cannot find an equivalent for g_object_newv()
in C#, that's why I'm stuck.
Any hints?
You may have figured this out already, but the CreateNativeObject call
in that generated call is the equivalent of g_object_newv. The string[]
is a list of property names. The GLib.Value[] is their corresponding
values.
--
Mike Kestner mkest...@gmail.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Gtk# 2.12.8 and Gtk# for .Net installer released
Announcing the release of Gtk# version 2.12.8. This is a bugfix release of bindings for the 2.12 API of Gtk+. Tarball is available for download from: http://ftp.gnome.org/pub/gnome/sources/gtk-sharp/2.12/gtk-sharp-2.12.8.tar.gz We are also announcing the simultaneous release of a new Gtk# for .Net installer: http://ftp.novell.com/pub/mono/gtk-sharp/gtk-sharp-2.12.8-1.win32.msi This installer fixes several issues with the previous release, including Mono.Cairo.dll reference key mismatches, missing 2.10 policy assemblies, missing key to detect installed runtime version, and failure to run pixbuf-loader setup script on vista. We appreciate everyone's patience as we've transition the maintenance of this installer upstream. Thanks also to all those who filed bug reports and acted as guinea-pigs as we worked through the issues. Beginning with this installer, we have integrated the VS.net development support key registrations into the previous runtime installer and are discontinuing the practice of releasing side-by-side Runtime and SDK installers. The SDK installer contained mainly C development files and at 31MB was a very large download just to get a few keys added to your Registry if you weren't interested in C development. The current installer gives you all you need for both runtime and managed development in a lightweight 8MB package. Any issues found with this release can be reported to the usual places, either in bugzilla.novell.com module gtk#, or gtk-sharp-l...@lists.ximian.com for discussion. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Help on deploying library to gac using autotools
On Fri, 2009-01-23 at 17:38 -0800, amrhassan wrote: Hi, I'm not an autotools expert. I just want to create a package to distribute my lib into GAC. I signed my library and everything, I created the Makefiles using the addin from MonoDevelop but I don't know how to get it to install the lib into GAC instead of PREFIX/lib. Can someone please help me with that? The way this is usually done is by building the assembly as a noinst_DATA target and adding something like: install-data-local: $(GACUTIL) /i $(ASSEMBLY) /f || exit 1; uninstall-local: $(GACUTIL) /u $(ASSEMBLY_NAME) /f || exit 1; ASSEMBLY_NAME is the name of your assembly without the .dll extension. ASSEMBLY includes the .dll. GACUTIL is setup in configure.in as: AC_PATH_PROG(GACUTIL, gacutil, no) if test x$GACUTIL = xno ; then AC_MSG_ERROR([No gacutil tool found. You need to install either the mono or .Net SDK.]) fi AC_SUBST(GACUTIL) -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-find-(provides|requires)
On Sat, 2008-12-13 at 15:23 +, Jonathan Pryor wrote: On Fri, 2008-12-12 at 22:35 -0600, Mike Kestner wrote: On Fri, 2008-12-12 at 08:56 -0700, Andrew Jorgensen wrote: I don't know how best to solve this issue but it needs to be solved. As more mono-based packages are added to linux distributions the problem will grow. Please share your well-reasoned ideas and / or proposed patches. We seem to have 3 classes of DLLs now: gac, addin, and private. I'm not entirely sure that we want to distinguish between addins and private. Somewhat because it's additional code to write/test, but mostly because I can't see this covering the log4net case, in which a plugin/addin/etc. wants to make use of the application's copy of e.g. log4net.dll (as presumably log4net won't be an addin any time soon). The advantage to doing so is not cluttering up the provides output with an entry for every non-gac assembly in an rpm when the majority of them are not realistically consumable at runtime. AFAICT, it solves the log4net problem as described because only the log4net rpm would advertise a provides for mono(log4net). It appears to be a gac installed assembly by that rpm. The mojoportal rpm would not advertise a provides, because it apparently installs the assembly to a private dir. mojoportal would not have a requires for it since it installs a copy itself. smuxi on the other hand would have a requires since it does not install log4net.dll, but instead uses the gac'd copy from log4net.rpm -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-find-(provides|requires)
On Fri, 2008-12-12 at 08:56 -0700, Andrew Jorgensen wrote: I don't know how best to solve this issue but it needs to be solved. As more mono-based packages are added to linux distributions the problem will grow. Please share your well-reasoned ideas and / or proposed patches. We seem to have 3 classes of DLLs now: gac, addin, and private. gac is obvious: Anything that installs one provides it, anything that references one requires it. private is any installed non-gac assembly which is not associated with addins. This includes local libraries installed by apps for their own use, and unstable libraries using the guidelines per the wiki. There is no reason for these libraries to be advertised as provides. The tricky one is addin-related libraries, like MonoDevelop.Core.dll which is consumed by Boo. These are loaded via the addin manifest dependency mechanism so they don't have to be installed in the GAC to be public. From a package dependency standpoint, any assembly reference not installed by the rpm itself needs to be listed by mono-find-requires. For mono-find-provides, gac and addin assemblies need to be listed. Gac libraries are easy enough to identify. Lluis and I were discussing it and he said it should be possible to extend the addin tools to provide an addin detection capability. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 2.12.6 installers for .Net
We are now announcing the availability of win32 runtime and sdk installers for Gtk# 2.12.6 via the mono project download page: http://mono-project.com/Downloads These installers are built on the upstreamed sources (now in svn trunk module win32-installers) which were used by Medsphere to provide 2.10 installers via the OpenVista project. We would like to thank Medsphere for providing this service to the community, and in particular Cody Russell and Brad Taylor for their efforts in the past and hopefully future to keep improving on these installers. The installers also build on the gtk+ binary distribution provided by gtk.org. The Novell release team is currently working feverishly to update the mono combined installer to Gtk# 2.12.6 as well, and we will be announcing that availability in the coming days. Since I know the question will be coming, now that win64 binaries are available from gtk.org for the gtk+ stack, we will be working to provide win64 installers for at least the .Net runtime. There are some challenges to work through, not the least of which being time and availability with all the various priorities coming at us. If you'd like to help with this effort, please let us know. The coming months will be very busy. We will be branching for 2.13.x unstable development once mono 2.2 is released. We have several nice enhancements in the works or planned for 2.14, like class virtual method support (thanks to Christian), glue reduction/elimination, more friendly win32 build process, and the new gio APIs (thanks to Stephane) plus all the new gtk+ goodies. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug in configure script of gtksourceview-sharp
On Thu, 2008-11-20 at 18:23 +0300, Alexander M. Batishchev wrote: http://anonsvn.mono-project.com/viewvc/branches/gtksourceview-sharp-0.x/ and ran ./configure. It said: checking for gapi2-fixup... /usr/local/bin/gapi2-fixup checking for gapi2-codegen... /usr/local/bin/gapi2-codegen But it's wrong, this applications are contained into /usr/bin/, because i have installed gtk-sharp into /usr, not /usr/local. If configure is reporting those paths it is because you have a copy of gtk-sharp installed in /usr/local. /usr/local/bin is typically on the PATH before /usr/bin, so configure will always find tools there before it looks in /usr/bin. If you don't want to use the version you have installed in /usr/local, you will either have to uninstall it, or adjust your PATH (and probably PKG_CONFIG_PATH and LD_LIBRARY_PATH) to not include /usr/local. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Build / Release team meeting with Miguel notes...
On Mon, 2008-11-10 at 17:17 -0700, Thomas Wiest wrote: * Make the Mono windows installer a smaller download - Split gtk# out into it's own component - Strip out the static libraries (the .a's) - Change the gtk# installer to install to both the MS and Mono GACs This is an awesome idea. Gtk# trunk, and therefore 2.12.6 already has an msm/wix build set up which can be invoked with: make win32-installer There is also a win32-installers module which builds msms for gtk+ and glade and the dependencies using wix. It also produces a runtime and sdk .msi for gtk-sharp + gtk + deps via automake. You just have to copy the msms produced by the gtk-sharp build into the root directory and do a make. This installer currently specifies a dependency for .Net 1.1 or greater, but maybe that wix dependency could be revised to test for a mono msi as well. The assembly installation is already done using gacutil, so maybe it will 'just work' with a mono provided gacutil. Brad and Cody are the gurus on this stuff. I've tinkered around enough with it to know how to do minor version updates and so on. I'd be happy to work with you guys to see if we can move this idea forward. I have a 2.12.6 installer sitting on my win32 machine right now which I was going to see about uploading to mono-project.com, but maybe we can use this release as an opportunity to get you guys started by rebuilding it on your build machine(s). * Change the Mono windows installer over to Wix so that it is an MSI There are a bunch of wix files in svn now to borrow from. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] why does gtk# installer requires .net 1.1 ?
On Thu, 2008-10-09 at 10:07 +0300, Onur Gumus wrote: It seems gtk# requires .net 1.1 explicitly for windows. Though this seems to be an unrealistic requirement if people want GTK# usage increase on windows as well. As you would guess, vast majority of windows boxes has .net 2.0+. Any improvements possible ? Right now, gtk-sharp requires the 1.1 SDK to build. Starting with the 2.10 installers though, I'm told that the installer doesn't require 1.1. There is no technical reason I am aware of that the gtk-sharp assemblies should require 1.1 at runtime. Can you confirm which installer you are referring to? -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Gtk# Status and Roadmap
In anticipation of the upcoming GNOME 2.24 release we have completed the gnomeprint and gnomepanel restructuring discussed and announced this spring. Beginning with release 2.24.0, the Gnome.Print and Gnome.PanelApplet APIs have been moved from gnome-sharp.dll into their own assemblies distributed in the gnome-desktop-sharp package. This move was necessary to allow the GNOME project to remove the gnomeprint libraries from their desktop release. If you are using either of these APIs, you will need to add configuration checks or -pkg: entries for the new pkgconfig files: gnome-print-sharp-2.18.pc and gnome-panel-sharp-2.24.pc. No other changes should be necessary, as the APIs themselves did not change, just their location. Note, however, that their location in gnome-desktop-sharp more accurately reflects the instability of the underlying APIs. Since gnomeprint is deprecated, it is unlikely to change. We will attempt to keep gnome-panel-sharp stable as much as possible, but the underlying C API has no stability guarantee. Gnome 2.24 will ship with gtk-sharp-2.12.3, gnome-sharp-2.24.0, and gnome-desktop-sharp-2.24.0. These tarballs have been uploaded to the gnome FTP servers. We currently plan to release gtk-sharp 2.14 in the GNOME 2.26 release next spring. The 2.14 release will integrate the existing gio-sharp bindings from trunk svn into the gtk-sharp package, as well as updating the existing assemblies to add the new 2.14 API. There are no plans for new GAPI features in this release. Looking farther down the road, Gtk+ appears to be solidly on a course to break API stability with a 3.0 release. The branch toward that goal is currently slated for around this time next year, releasing a 2.90 release alongside 2.16. The 3.0 stable release is not planned until significant new features have been added. The 2.90 release will remove all deprecated APIs and hide all structure fields. Our current long-term strategy for gtk-sharp is to continue to release gtk-sharp 2.x in the GNOME release following its corresponding gtk+ release. With the 3.0 picture still fuzzy, we are reserving judgment on when we will move to it and how much of an API break we will do in gtk-sharp alongside the C break. Whenever it occurs, gtk-sharp-3.0 will be parallel-installable with gtk-sharp-2.0 to allow for migration to the new version at the user's pace. If you want to get a jump on the transition, you will want to begin moving your use of any Obsolete/deprecated API to its replacement. Transition guides for most major C deprecations are available in the gtk + documentation on gtk.org. As always, we appreciate any feedback from the community. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gstreamer-sharp Question
On Thu, 2008-05-29 at 16:54 -0700, C.J. Adams-Collier wrote: Aaron, Did you build this binding manually, or did you use gapi2? Mike, Is there any reason why gapi2 wouldn't work on gstreamer? My understanding is that the problem with a straight gapi binding was that there are proprietary gstreamer plugins which can't be GAPI-fied to identify all the APIs they expose, so there is need for more dynamic access to signals/events and properties of Gst.Elements. The gstreamer bindings effort undertaken during SoC a few years back was at least partially focused on this dynamic signal invocation and connection mechanism. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Strange GdkSharp.PixbufDestroyNotifyWrapper error..
On Sat, 2008-05-31 at 21:50 -0400, [EMAIL PROTECTED] wrote: On Fri, 2008-05-30 at 17:00 -0400, [EMAIL PROTECTED] wrote: ExcObject: System.InvalidProgramException: Invalid IL code in (wrapper native-to-managed) GdkSharp.PixbufDestroyNotifyWrapper:NativeCallback (intptr,intptr): IL_0030: call 0x0006 Actually, I guess this IL problem required a fix in mono, according to Zoltan on: https://bugzilla.novell.com/show_bug.cgi?id=362951 The patch I committed yesterday fixes an exception that would have come out if you had his fix. any alternatives?? (build the object in other way, use a temporary object to do..something..), I really need to fix this and checkout+patch and recompile all mono or gtk-sharp sources don't seems to be a easy solution :-S, also wait to next rpm released is kind of long time ;-) , sugestions?, may be is posible to use a compiled version from you? I would really apreciate if that is posible and fix the problem.. PibxbufLoader may have some alternatives. Wade is building snapshot builds for gtk-sharp trunk if you are running openSUSE: http://mono.ximian.com/monobuild/snapshot/download-trunk/ Based on the rpm version for gtk-sharp2, it looks like the latest snapshot is for r100145 though. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Strange GdkSharp.PixbufDestroyNotifyWrapper error..
On Fri, 2008-05-30 at 17:00 -0400, [EMAIL PROTECTED] wrote: ExcObject: System.InvalidProgramException: Invalid IL code in (wrapper native-to-managed) GdkSharp.PixbufDestroyNotifyWrapper:NativeCallback (intptr,intptr): IL_0030: call 0x0006 I think this is a known issue with PixbufDestroyNotifyNative using a byte[] for the pixbuf parameter without the appropriate [MarshalAs] magic. I just committed a patch to gtk-sharp trunk (revision 104582) which should resolve the issue. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building gtk-sharp 1.0.10 problem
On Fri, 2008-05-09 at 11:00 +0100, Paul wrote: Hi, I'm rebuilding gtk-sharp for inclusion in Fedora and have hit a problem when building rsvg. What non-C# library do I need to have installed to ensure that rsvg gets built? librsvg, but most likely, the problem is that you don't have an old enough librsvg installed to get the appropriate .pc file. Modern librsvg installs a librsvg-2.0.pc. Do you have an app that has a 1.0.x dependency? You are probably better off just packaging the gtk-sharp-2.x version corresponding to the installed gtk+. gtk-sharp-1.0.x hasn't received any love in over 3 years now. We have stopped packaging it on mono-project.com/Downloads. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.9.0 Preview 3 is out - mono 1.9 pre3 / gtk# 2.10.3 not working on Win32
On Mon, 2008-02-25 at 18:41 -0800, Daniel Morgan wrote: I'm not sure if there is a bug for this or not. There is not. Please file one with specifics. The gtk# 2.10.3 that comes with the mono 1.9.0 preview 3 windows installer is broken. In particular, setting or getting a value from a tree model. I do not have this issue in mono 1.2.6 / gtk# 2.10.2 for windows. If you plan on releasing mono 1.9 soon, then please revert to an earlier gtk# 2.10.2 please. I doubt this would help, since there have been no reported problems with the 2.10.3 installer for the MS runtime and it passed testing at Medsphere. I suspect either there is an issue on mono 1.9 or one with the installer build. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing Gtk# release 2.10.3 and Gnome# release 2.16.1
We are pleased to announce version 2.10.3 of Gtk# and version 2.16.1 of Gnome# . Packages are available for supported platforms at: http://mono-project.com/Downloads Source tarballs have been uploaded to ftp.gnome.org. I'm also happy to announce a coordinated release of Gtk# for the MS runtime produced by the folks at Medsphere. It is available for download at: http://sourceforge.net/project/showfiles.php?group_id=74626package_id=223067 This is a bugfix release with limited new API additions. Users of the impending mono 1.9 release should upgrade their 2.10/2.16 installs to this release to avoid a potential problem in glade-sharp resulting from recent System.Reflection changes. What is Gtk#: Gtk# and Gnome# are a set of .Net/mono language bindings to assorted Gtk + and GNOME libraries. Supported libraries include pango, atk, gtk+, libglade, libgnome, libgnomeui, libgnomecanvas, libgnomeprint, libgnomeprintui, libpanelapplet, librsvg, libvte, libgtkhtml, and gconf. What's new in version 2.10.3: - Performance, memory management, and object finalization improvements. - GLib.ExceptionManager to support exception handling in signal callbacks. - GLib.IOChannel and GLib.Spawn classes for process spawning. - Numerous bugfixes Thanks to the contributors to this release: Wade Berrier, Eskil Bylund, Sebastian Dröge, Michael Hutchinson, Peter Johanson, Lluis Sanchez Gaul, and myself. Discussion of Gtk# occurs on [EMAIL PROTECTED] and defects can be reported to bugzilla.novell.com, module gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing Gtk# release 2.8.5
We are pleased to announce release 2.8.5 of Gtk#. Packages are available for supported platforms at: http://mono-project.com/Downloads Source tarball has been uploaded to ftp.gnome.org. This is a bugfix release with limited new API additions. Users of the impending mono 1.9 release should upgrade their 2.8 installs to this release to avoid a potential problem in glade-sharp resulting from recent System.Reflection changes. What is Gtk#: Gtk# is a set of .Net/mono language bindings to assorted Gtk+ and GNOME libraries. Supported libraries include pango, atk, gtk+, libglade, libgnome, libgnomeui, libgnomecanvas, libgnomeprint, libgnomeprintui, libpanelapplet, librsvg, libvte, libgtkhtml, and gconf. What's new in version 2.8.5: - Performance, memory management, and object finalization improvements. - GLib.ExceptionManager to support exception handling in signal callbacks. - Numerous bugfixes Thanks to the contributors to this release: Wade Berrier, Eskil Bylund, Sebastian Dröge, Michael Hutchinson, Lluis Sanchez Gaul, and myself. Discussion of Gtk# occurs on [EMAIL PROTECTED] and defects can be reported to bugzilla.novell.com, module gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Gtk# release 2.10.3 and Gnome# release 2.16.1
On Wed, 2008-02-13 at 22:17 +0200, Vladimir Dimitrov wrote: Hello, Sorry about the stupid question but why would I use Gtk# 2.8.5 when there is Gtk# 2.10.3??? Is there any other reason than that I cannot reference and build apps against older versions of Gtk# if I don't have them installed (policies didn't work for me with VS 2005) It was released for support of older platforms which are built on gtk+ version 2.8 and therefore cannot provide Gtk# 2.10.x. If all the platforms you want to support ship gtk+-2.10.0 or later versions, Gtk# 2.10.3 is probably what you want. Our windows installers both provide 2.10.x currently. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing Preview Release for Gtk 2.12 and Gnome 2.20 bindings
We are announcing the first public preview release of bindings for the Gtk 2.12 and Gnome 2.20 APIs. These releases are not API-stable yet, but are sufficiently mature to begin testing against. Anticipated API adjustments are expected to be minimal at this point but might occur until we reach the stable 2.12.0 and 2.20.0 versions. The gtk-sharp package contains bindings for glib, pango, atk, gdk, gtk, and glade. The API versions bound correspond to the versions shipped in the GNOME 2.20 platform release set. The gnome-sharp package binding set has changed with this release. Remaining in gnome-sharp are art, gnomevfs, libgnome, libgnomeui, libgnomeprint, libgnomeprintui, libpanelapplet, libgnomecanvas, and gconf bindings. The gnome-desktop-sharp package contains updated versions of the gtkhtml, rsvg and vte bindings previously shipped in gnome-sharp, as well as new bindings for libgnome-desktop, libnautilus-burn, and libwnck. We expect to add gtksourceview2 bindings as well prior to the final release. Bindings shipped in this package are not guaranteed to be API stable since the underlying libraries are not guaranteed API stable. Attempts will be made to maintain compatibility where possible, using policy assemblies. When API compatibility is broken in underlying libraries, the associated bindings will be parallel-installable with prior versions. Testing packages for openSUSE 10.3 and Fedora 8 can be found at: http://download.opensuse.org/repositories/home:/mkestner/ Source tarballs are available from ftp.gnome.org. We expect to move rapidly toward the 2.12 and 2.20 final release, with possibly one more preview depending on the number of issues identified. Issues can be reported to bugzilla.novell.com module gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing the 2nd Preview Release for Gtk 2.12 and Gnome 2.20 bindings
We are announcing the second public preview release of bindings for the Gnome 2.20 APIs. This release includes gnome-sharp-2.19.91 and gnome-desktop-sharp-2.19.1 to fix configuration and API stability issues identified in the initial release. The gtk-sharp package remains at version 2.11.91 released last week. Tarballs are available from ftp.gnome.org, and packages for Fedora8 and OpenSUSE 10.3 are available at: http://download.opensuse.org/repositories/home:/mkestner/ These releases are not API-stable yet, but are sufficiently mature to begin testing against. Anticipated API adjustments are expected to be minimal at this point but might occur until we reach the stable 2.12.0 and 2.20.0 versions. The gtk-sharp package contains bindings for glib, pango, atk, gdk, gtk, and glade. The API versions bound correspond to the versions shipped in the GNOME 2.20 platform release set. The gnome-sharp package binding set has changed with this release. Remaining in gnome-sharp are art, gnomevfs, libgnome, libgnomeui, libgnomeprint, libgnomeprintui, libpanelapplet, libgnomecanvas, and gconf bindings. The gnome-desktop-sharp package contains updated versions of the gtkhtml, rsvg and vte bindings previously shipped in gnome-sharp, as well as new bindings for libgnome-desktop, libnautilus-burn, and libwnck. We expect to add gtksourceview2 bindings as well prior to the final release. Bindings shipped in this package are not guaranteed to be API stable since the underlying libraries are not guaranteed API stable. Attempts will be made to maintain compatibility where possible, using policy assemblies. When API compatibility is broken in underlying libraries, the associated bindings will be parallel-installable with prior versions. Testing packages for openSUSE 10.3 and Fedora 8 can be found at: http://download.opensuse.org/repositories/home:/mkestner/ Source tarballs are available from ftp.gnome.org. We expect to move rapidly toward the 2.12 and 2.20 final release, with possibly one more preview depending on the number of issues identified. Issues can be reported to bugzilla.novell.com module gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Adding signal support to gapi genrated binding
On Sat, 2008-01-05 at 20:03 +0100, Fabian Sturm wrote: One unsolved thing is that I now get a warning for every signal I added. Can this be ignored or is this the norm? mcs -pkg:gtk-sharp-2.0 -target:library -out:generated/abiword-sharp.dll generated/*.cs generated/AbiWidget.cs(222,37): warning CS0169: The private method `Abiword.AbiWidget.OverrideTableState(GLib.GType)' is never used generated/AbiWidget.cs(291,37): warning CS0169: The private method `Abiword.AbiWidget.OverrideJustifyAlign(GLib.GType)' is never used It's normal. We use -nowarn:0169,0612,0618 in gtk-sharp on the csc/mcs command line for generated source compilations to avoid the spew. The errors you see are related to methods the GLib.Object type registration code invokes via reflection to hook overridden virtual methods into the type's class struct. The compiler has no way to know they will be used in that manner. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-docs-list] Can not checkout trunk on windows
On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: Suggestions? All I can suggest is that namespace XML files should contain some character/string that namespaces are highly unlikely to contain, e.g. instead of en/System.xml for the XML documentation on the System namespace, use en/Namespace-System.xml. Any such character/string *must* be usable on Windows, so no ':' or similar characters can be used. We should add support for a different name like: ns-System.xml And then we can rename the files for the docs that we maintain. An alternative might be to use a namespaces.xml file in the root node which contains all the namespace summary docs for the directory. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Addins in Monodoc
On Thu, 2007-12-20 at 14:56 +0100, Lluis Sanchez wrote: The idea is that Mike wants to switch to use GtkTextView to render the documentation, and at the same time, this would allow us to implement editing very easily. Even if GtkHtml is very limited, it is much better than GtkTextView in rendering text. At least it can render tables, borders, change background colors, etc. GtkTextView can't do that. It won't be a TextView, though it may embed one in editing mode if that makes things easier. When Miguel and I talked on the phone, I said Custom Gtk# Widget though I can understand how he could have assumed it would be a TextView subclass. Maybe implementing editing would be easier with GtkTextView, but most of people will use MonoDoc for reading rather than writing documentation. So I don't think reducing the text rendering capabilities to make it easier to edit documentation is a good deal. I don't recall anyone mentioning Reduce Text Rendering Capabilities as a feature for the revisions. I'll try to spend some time developing a plan in the next couple weeks and publish it so everyone can poke holes in it. A couple things are fairly clear to me: 1. Using an HTML widget for monodoc rendering is overkill for the layout we require, and providing Gecko and GtkHTML on all the platforms we want to target with monodoc is a PITA. 2. Adding WYSIWYG editing to any tool which is based on an HTML widget rendering information already passed through an xslt transformation is going to be problematic. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TreeModelAdapter vs CellRendererCombo
Miguel de Icaza wrote: There are a handful of Gtk# questions. I just forwarded one. Subject: [Mono-dev] TreeModelAdapter vs CellRendererCombo From: Magnus Henoch [EMAIL PROTECTED] Date: Mon, 15 Oct 2007 12:11:29 +0200 To: mono-devel-list@lists.ximian.com To: mono-devel-list@lists.ximian.com Please send questions about Gtk# to gtk-sharp-list in the future, so we can keep the discussion archives in one place where others will hopefully find them. However, when I try to use it with a CellRendererCombo: combo = CellRendererCombo() combo.Model = TreeModelAdapter(chainsModel) combo.TextColumn = 0 combo.Editable = true I get this warning: (editor:8956): GLib-GObject-WARNING **: unable to set property `model' of type `GtkTreeModel' from value of type `GtkSharpValue' and the combo box does nothing when clicked. Is this a bug or user error? Bug. I need to add a GLib.Value ctor for the interface adapters. I'll commit a fix to trunk. Thanks for the report. Mike ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Portal.CLI: Various managed bindings for common UNIX/Linux libraries
On Thu, 2006-08-10 at 22:44 -0400, William Lahti wrote: - libpangocairo (to access pango# with cairo, may be unnecessary if pango# has expanded since I've checked) As of yesterday, pango-sharp binds the majority of pangocairo.h. If there is a useful method missing that isn't clearly backend code, I'd like to hear about it. -- Mike Kestner [EMAIL PROTECTED] SUSE® Linux Enterprise 10 Your Linux is ready™ www.novell.com/linux ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] PanelApplet issue
On Thu, 2006-07-27 at 21:20 +0200, Tobias Schlitt wrote: Hi all! Since the Gtk list seems pretty orphan to me, I take the liberty to post this issue here. Please be patient with me! You might want to wait more than 10 hours before you start cross-posting next time. I've responded to your question on gtk-sharp-list, where the discussion belongs. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gtk# not found
On Fri, 2006-03-31 at 16:04 +0100, [EMAIL PROTECTED] wrote: That instalation of mono worked. My program seemed to run fine. In the mean time, i noticed that there is another version of mono, 1.1.13.6, and went to try that one. It still gives the same problem. For watever reason, your experimental installer for Windows runs my Gtk# 2.4 application while the official mono one does not (neither in Windows nor in Linux)... Talked to Wade about this today and we think we figured out why the mono-project installers policy stuff wasn't working. He's working on the issue. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono 1.1.14 WIN32 runtime error
On Tue, 2006-04-04 at 16:48 -0600, Peter Dennis Bartok wrote: Already logged here: http://bugzilla.ximian.com/show_bug.cgi?id=77896 Many people are running into this. Seems to pretty much render Winforms useless on Win32. Waiting for Paolo on that one. Paolo checked in a fix for this. It's on svn trunk. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Gtk-sharp-list] Re: [Mono-dev] Merge gtkpell-sharp into gtk-sharp?
On Thu, 2006-03-09 at 17:16 -0500, Miguel de Icaza wrote: We are trying to make Gtk# smaller, not larger ;-) Amen, brother. :-) Seriously, though, it is unlikely we will add any library to Gtk# that is outside the Gnome Platform release, at this point. Since gtkspell isn't even part of the Gnome Desktop release set, I don't think it should be included in Gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [OT] No way to create account on mono-project?
On Wed, 2006-02-22 at 10:03 -0900, Joshua Kugler wrote: On Wednesday 22 February 2006 09:55, Richard Torkar wrote: On Feb 22, 2006, at 19:27 , Joshua Kugler wrote: OK, my first one. :) On http://www.mono-project.com/Languages it points to IronPython via the URL http://www.ironpython.com/. While technically correct, that site seems to be no longer active. The URL for the active site is http://www.gotdotnet.com/workspaces/workspace.aspx?id=ad7acff7- ab1e-4bcb-99c0-57ac5a3a9742 Hope that helps. Well actually, I'd prefer this link: http://workspaces.gotdotnet.com/ ironpython Oh, yeah, so would I. Didn't realize it worked that way. Thanks. Done, thanks. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: [Mono-patches] r55877 - trunk/mono-tools
On Wed, 2006-02-08 at 21:49 -0700, Wade Berrier wrote: Currently the monodoc browser is available on many older distros as well as win32. But with this change it won't work on older distros nor win32. It looks like sles9, rh9, and rhel3 are the only distros mono is packaging that don't have Gtk#2 packages at this point. It seems reasonable to freeze at the previous version of monodoc-browser for those platforms. Those platforms just don't get new features and live with the existing bugs. We can continue to update the documentation content independently since that lives in monodoc, not mono-tools. As far as win32, is it the gconf-sharp dependency that's blocking us? How did you get around that for 1.0 on win32? -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Integrating C# and already existing C sources using GAPI or something similar
On Mon, 2006-01-23 at 12:39 +0100, Mario Sánchez wrote: Hi, this is my first message to this list, so I'll try to do it my best... This message should have been sent to gtk-sharp-list. Discussion of Gtk# and the GAPI tools should occur there. I'm going to start nagging everyone about this from now on, as people seem to think Gtk# discussion is on topic on this list as well, and that just means duplicate discussions are happening and it's harder to find information in the archives. I'm currently working at a Gtk application and now I'm trying to make an small part of the already-made gtk interface (a simple use case of the whole application) using Mono with Gtk#, to see how this integration could work. As you can imagine, I'd like to use the most already written source code I can, so I'd like to call already written C functions from my new C# interface, using a Wrapper for that purpose. And this is the point in which I'm now stalled: Another option for a large code base would be to embed mono into your existing C application to extend it. That's on-topic for this list, but I don't know much about it so I'll let others comment on it. 1.- I'd like to generate wrappers for a source directory and sub-directories of a currently installed library, and I don't know how to make this without explicitly specify those directories one-by-one in the parsing gapi source file, as you can see here: Look in the gtk-sharp/sources directory for examples of how to combine multiple source directories and even multiple native libraries into a single api file. The Gdk and Gnome api file sections demonstrate this. 2.-I have more source code that I'd like to re-use but that is not installed as a library, because it's not a library but an application (the application in which I'm trying to re-implement a use case in Mono terms), but it has got, for example, several defined Gobjects and utilities that are useful for me to use from my Gtk# interface. The question is how could I automatically wrap those sources using Gapi (or something similar) into C# files, in order not to have to implement that already-written functionality again. GAPI is not a C to C# translator. It won't transform C code into C#. It uses the DllImport/PInvoke capability of .Net/mono to invoke native library methods. So short answer is, no library, no GAPI. 3.- Another question using GAPI is how to wrap C sources that not correspond to GObject classes because, as I was able to see, gapi parser only recognizes those sources that represent classes using GObject, but not those other C sources as could be utility libraries containing useful functions for common situations at this application. GAPI does parse some non-GObject libraries already, although it is not a full-featured C parser. Non-GObject libraries tend to not follow the same coding conventions as GObject libraries. I'll be so glad if someone was able to help me, because I can't find enough information and documentation about the Gapi parser across the Internet, so I can't find the way to achieve this issues. I'm open to other suggestions (not only Gapi) for me to integrate C# and C in the way I mean too, so if someone knows a better way to do this I'll be interested on it. The definitive resource for GAPI is: http://www.mono-project.com/GAPI -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] vte-sharp and Fedora Core
On Sun, 2006-01-22 at 17:59 +, Paul wrote: Can someone please check in the patch provided for bug 16381 as without it, vte-sharp will continually fail to build under Fedora Core. I'm assuming you mean attachment 16381 to bug 77323. Nice to see a workaround suggestion I made a month ago come back as a proposed fix: http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016303.html I have attached a note to your vte bug report indicating why it should be reopened despite the fact that a workaround exists for Gtk#. But since I'm getting really tired of wasting time on this issue, I have decided to patch the gtk-sharp configure.in.in to add gtk+-2.0 to the VTE_DEPENDENCIES pkgconfig check, which I suppose is a moderately less hackish workaround. It's on trunk revision 55928. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] x86_64 and building
On Sun, 2005-12-18 at 18:06 -0800, Todd Berman wrote: So far, I've no problems getting mono/mcs and libgdiplus to build. However, I can't get gtk-sharp to build (it bombs out moaning that .net or mono needs to be installed - so I'm guessing there is a problem with the current build script). I'm fine putting that into bugzilla, but can anyone else using an x86_64 box confirm it? works for me here. sounds like a local issue. My main Gtk# development machine is amd64, so I'll second Todd's motion. There are 3 moaning that .net or mono needs to be installed messages, but 2 specify gacutil and al as a specific missing requirement too. So since you didn't mention that I suspect it is the 3rd one which results from not finding mono.pc and AC_PATH_PROG not finding csc.exe. Since you are building on mono, apparently your issue is a failure to find mono.pc. On a 64 bit build I would suspect the whole libdir=lib64 thing. Mono is most likely stuffing the pc file in prefix/lib/pkgconfig. Make sure your PKG_CONFIG_PATH isn't doing something like prefix/lib64/pkgconfig. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono-find-provides
The following patch is a stab at extending mono-find-provides to
identify assembly versions supported by policy assemblies. The script
currently exposes the policy assemblies as:
mono(policy.2.4.gtk-sharp) = 0.0.0.0
instead of the desired:
mono(gtk-sharp) = 2.4.0.0
Will commit unless somebody can think of a better way.
--
Mike Kestner [EMAIL PROTECTED]
Index: scripts/mono-find-provides.in
===
--- scripts/mono-find-provides.in (revision 53695)
+++ scripts/mono-find-provides.in (working copy)
@@ -35,6 +35,14 @@
/^Version:/ { VERSION=$2 }
/^Name:/{ LIBNAME=$2 }
END {
+ if (LIBNAME ~ /^policy/) {
+cnt = split(LIBNAME, toks, .)
+VERSION=toks[2] . toks[3] .0.0
+LIBNAME=
+for (i=4; i= cnt; i++)
+ LIBNAME = (LIBNAME toks[i] .)
+LIBNAME=substr(LIBNAME, 1, length(LIBNAME)-1)
+ }
if (VERSION LIBNAME)
print mono( LIBNAME ) = VERSION
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch for Mono.Cairo to rename Graphics to Context
On Mon, 2005-11-28 at 21:10 -0500, John Luke wrote:
Hello,
Here is a patch that renames the Graphics class to Context, like all the
other cairo bindings use. It would be a breaking change, but I think it
will be less confusing for developers. Please speak up if you disagree.
There is one other API change I think would be nice, but I dont think
I'll have time to do it this week. That is to change PointD, Color, etc
to structs and rename PointD to Point. Everything else should be able
to be handled in an API compatible way.
Seems like a gratuitous change to me.
We are already exposing Cairo.Graphics in the 2.7.1 release of Gtk#.
It's an unstable release, so I can change the symbol still, but the
change as posted would break 2.7.1 on newer mono releases.
If this change is going to be made, at the very least I would suggest
adding something like:
[Obsolete (Replaced by Cairo.Context)]
public class Graphics : Context {}
That would at least give source compat, if not runtime compat. But I
don't personally think it's worth changing just to be consistent with
other language bindings.
--
Mike Kestner [EMAIL PROTECTED]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch for Mono.Cairo to rename Graphics to Context
On Tue, 2005-11-29 at 12:40 -0500, John Luke wrote:
[Obsolete (Replaced by Cairo.Context)]
public class Graphics : Context {}
I would rather not make the change if we have to add Obsolete API, I
consider that an even more likely source of confusion.
Peter pointed me to this:
http://www.cairographics.org/manual/language-bindings.html
Which clearly supports the change.
As far as confusion with Obsolete API, we need to add some support to
monodoc for stuffing obsolete API onto a special page or at least
highlighting summaries for obsolete members/types.
I guess we just need an official statement from Miguel as to whether the
Mono.Cairo API was ever declared stable. It has shipped with stable
releases already, but I don't know if that alone carries an expectation
of stability.
Since the Gtk# exposure of Cairo.Graphics is so new and unstable, we
could probably get around the issue by simultaneously releasing a new
Gtk# with the next mono release.
We also need to address the issue of Mono.Cairo availability on win32
with the MS runtime. We need to be able to build/ship Mono.Cairo
without mono on win32 for Gtk#.
--
Mike Kestner [EMAIL PROTECTED]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch for Mono.Cairo to rename Graphics to Context
On Tue, 2005-11-29 at 15:53 -0500, John Luke wrote: On Tue, 2005-11-29 at 12:07 -0600, Mike Kestner wrote: We also need to address the issue of Mono.Cairo availability on win32 with the MS runtime. We need to be able to build/ship Mono.Cairo without mono on win32 for Gtk#. This already works (for gtk2.8), or are you referring to making it easier/automatic? Right now, we only reference Mono.Cairo.dll on non-win32 platforms, so 2.7.1 probably doesn't even build out of the box on win32. We need a way to detect if Mono.Cairo is installed (ie mono-cairo.pc) and make 2.7.x depend on that. We can't just depend on mono.pc because the MS runtime is a primary win32 target for Gtk#. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Gnome.Vfs Initialization
On Thu, 2005-11-17 at 04:48 -0700, Buderya Roshan wrote: Before we can use Gnome.Vfs APIs to read remote files, do we need to initialize it? If so which API is used? I didn't find a suitable API in monodoc. Any help is appreciated. Are you doing a Gtk.Application.Init? That seems to be all that sample/TestVfs does. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Right MCS in Path, Configure Gets Wrong MCS
On Thu, 2005-09-22 at 02:16 -0700, Todd Berman wrote: `which mcs` returns the expected /home/stephen/bin/mono-svn/bin/mcs. When I run ./bootstrap-2.4 --prefix=/home/stephen/bin/mono-svn/, however, I get the following summary after configure runs: Configuration summary * Installation prefix = /home/stephen/bin/mono-svn/ * C# compiler: /usr/bin/mcs My best guess is to make sure that your PKG_CONFIG_PATH contains /home/stephen/bin/mono-svn/lib/pkgconfig/ as I believe gtk# checks for mcs using the location of the mono.pc, but I could be wrong. You're wrong. ;-) AC_PATH_PROG(CSC, mcs, no) I don't have any idea how that could be failing to return the mcs from your path. That's pretty fundamental autoconf stuff. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem compiling gtk-sharp
On Tue, 2005-08-23 at 15:53 +0100, Paul wrote: Hi, I'm trying to compile gtk-sharp with the -for-the-insane bootstrap. It will compile so far and then gives the following Is this a mcs problem and if it is, has it been reported yet? You may be the first person to attempt compiling it. I haven't because I haven't taken the time to get a Gtk+ 2.8 installation up. It's totally unsupported until we get 2.4/2.6 out. That's why the script is marketed at insane people, in case they might want to fix it on their own. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem compiling gtk-sharp
On Tue, 2005-08-23 at 17:13 +0100, Paul wrote: By the looks of it though, the problem is not in gtk-sharp, but mcs. I'll put into bugzilla anyway. That exception is occurring during the code generation target, so I seriously doubt it's mcs. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Mono and Ubuntu 5.10 Release Schedule
On Sun, 2005-07-03 at 12:16 -0400, Brandon Hale wrote: I've already spoken with Mike, Ben, and Miguel on IRC, but I would appreciate any creative solutions to either API or scheduling issues that you can come up with. Anybody ever tried doing a mono bundle with MD? -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] GUI Toolkits
On Wed, 2005-05-04 at 22:29 -0400, Thomas Harning Jr. wrote: About Gtk#... is there anything that I can do to prevent this exceptions? Yes, you can file bug reports with the complete exception trace. Sending an email to a list with no more detail than Gtk# likes to throw NullRefExceptions doesn't help much. I'm not sure what MonoDevelop's doing in the background and the UI code looks split throughout... so I wouldn't know where to look for problems (besides the fact that crashes seem extremely non-deterministic). The exception trace tells you exactly where to look. I've seen with sending delegates that you have to keep an instance in managed code if you're going to send it off to unmanaged realm as a function pointer [ex: for Tao.FreeGlut], which is a minor pain... but will certainly be worth it if I can use Gtk# in my apps. This is not necessary for the most part in Gtk# trunk any more. If there are still places where crashes occur because of released delegates, they should be reported as bugs. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: GObject Binding issues
On Fri, 2005-04-29 at 08:47 -0400, PAUL BETTS wrote: So using Glib != being GObject based then? What then would be a good way to generate C# wrappers for this library? Before I saw the GAPI article I was attempting to use Swig to generate the wrappers, but it'd be much better to leverage the existing Glib wrappers than to say compile everything statically and reinvent the wheel (like Adium does for its libgaim binding) GAPI can be used for non-GObject libraries. We do so with libart_lgpl in Gtk#. It looks like the problem you are hitting is that the assembly-name isn't being properly defaulted. Try providing a --assembly-name argument to your gapi2-codegen command. It's possible you may need to provide a --customdir option too. I've opened a bug to provide default values for missing arguments: http://bugzilla.ximian.com/show_bug.cgi?id=74769 -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Building gtk-sharp from Recent svn
On Sun, 2005-04-24 at 15:34 -0700, Joe Audette wrote: /.libs/libgtk-x11-2.0.so: undefined reference to `g_option_group_add_entries' /.libs/libgtk-x11-2.0.so: undefined reference to `g_return_if_fail_warning' Looks like you need glib 2.6, although I'm surprised you could build pango-1.8 without it. -- Mike Kestner [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
