From fejj at novell.com Mon Jun 2 16:51:48 2008 From: fejj at novell.com (Jeffrey Stedfast) Date: Mon, 02 Jun 2008 16:51:48 -0400 Subject: [Moonlight-list] beginnings of a patch to use cairo_glyph_t API Message-ID: <1212439908.4437.36.camel@tazmanian-devil.novell.com> This isn't yet completed, by any means... but I figured I'd send it to the list so it isn't lost at least, since it might be a little while before I get time to continue with it. I think the state of the patch is that it changed Glyphs elements to render using cairo_glyph_t, but it more-or-less broke TextBlock iirc. I think that ideally we probably want to use cairo_scaled_font_t's rather than cairo_font_face_t. I think that it's probably worth looking into this further, but my head hurts when I think about reworking the layout.cpp code to use this stuff so I am putting it aside for a bit :( Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: cairo-glyph.patch Type: text/x-patch Size: 19149 bytes Desc: not available Url : http://lists.ximian.com/pipermail/moonlight-list/attachments/20080602/09e2bc25/attachment-0001.bin From toshok at gmail.com Tue Jun 10 21:54:35 2008 From: toshok at gmail.com (Chris Toshok) Date: Tue, 10 Jun 2008 18:54:35 -0700 Subject: [Moonlight-list] 2.0 support changes Message-ID: I made a few changes, mostly to isolate the Silverlight 2.0 stuff that's in the source tree now from the 1.0 stuff. As it stands at the moment, there should be zero 2.0 specific code/types/anything included in the 1.0 build. This means both managed and unmanaged. Before we built all the 2.0 stuff and just left out the hooks to run 2.0 content in the 1.0 build. But there's no point in including additional code that's never going to run in a released 1.0 (nor is there a reason to waste time compiling the files at all in a 1.0 environment.) Keeping the managed side segregated is easy: We don't build any of it if 2.0 isn't enabled. The unmanaged side isn't as easy though, so here's some conventions I've implemented: 1. All 2.0 specific classes/methods/files/blocks of code/etc are wrapped in #if INCLUDE_MONO_RUNTIME. This was mostly partially done before. 2. All 2.0 specific dependencyobject descendants need a special typegen pragma of the form: /* @SilverlightVersion="2" */ on the line above the class declaration in their header files. If you grep for this string you'll find a number of examples. This enables the typegen machinery to wrap the generated code (and enum values) for these types in the proper #if INCLUDE_MONO_RUNTIME. 3. Files that are 2.0 specific are listed in a special block in src/Makefile.am, so they aren't compiled at all. Examples include grid.cpp, xap.cpp, deployment.cpp. The reason 2 is still needed even with 3 above is that typegen isn't smart enough (and it would be a pain to make it smart enough) to deal with 1.0 vs 2.0 files, and some files (control.h) have both 1.0 and 2.0 classes in the same file. I'm planning to go through and replace INCLUDE_MONO_RUNTIME with a better ifdef. There are a couple of possibilities: 1. SILVERLIGHT_VERSION, which we can use in comparisons, like "#if SILVERLIGHT_VERSION >= 2" 2. a scheme more like mcs/ uses, where we'll define SILVERLIGHT_2 in 2.0 builds, SILVERLIGHT_2 and SILVERLIGHT_3 in 3.0 builds, etc. Anyone have an opinion on which one to use? chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/moonlight-list/attachments/20080610/03ab1901/attachment.html From gnorton at novell.com Tue Jun 10 22:07:31 2008 From: gnorton at novell.com (Geoff Norton) Date: Tue, 10 Jun 2008 22:07:31 -0400 Subject: [Moonlight-list] 2.0 support changes In-Reply-To: References: Message-ID: <1213150051.6962.119.camel@limestone> On Tue, 2008-06-10 at 18:54 -0700, Chris Toshok wrote: > I'm planning to go through and replace INCLUDE_MONO_RUNTIME with a > better ifdef. There are a couple of possibilities: > 1. SILVERLIGHT_VERSION, which we can use in comparisons, like > "#if SILVERLIGHT_VERSION >= 2" > 2. a scheme more like mcs/ uses, where we'll define SILVERLIGHT_2 > in 2.0 builds, SILVERLIGHT_2 and SILVERLIGHT_3 in 3.0 builds, > etc. > Anyone have an opinion on which one to use? > I'm personally a fan of the mcs style, if its used consistently (another of our problems) its very easy to scan/parse what code is in what build. Parsing a (>)(<)(=) # is a few extra cycles. but thats just me -g From rolflists at ya.com Wed Jun 11 04:22:35 2008 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Wed, 11 Jun 2008 10:22:35 +0200 Subject: [Moonlight-list] 2.0 support changes In-Reply-To: <1213150051.6962.119.camel@limestone> References: <1213150051.6962.119.camel@limestone> Message-ID: <004e01c8cb9c$4ec8d360$ec5a7a20$@com> > -----Original Message----- > From: moonlight-list-bounces at lists.ximian.com [mailto:moonlight-list- > bounces at lists.ximian.com] On Behalf Of Geoff Norton > Sent: mi?rcoles, 11 de junio de 2008 4:08 > To: Chris Toshok > Cc: moonlight-list at lists.ximian.com > Subject: Re: [Moonlight-list] 2.0 support changes > > On Tue, 2008-06-10 at 18:54 -0700, Chris Toshok wrote: > > > I'm planning to go through and replace INCLUDE_MONO_RUNTIME with a > > better ifdef. There are a couple of possibilities: > > 1. SILVERLIGHT_VERSION, which we can use in comparisons, like > > "#if SILVERLIGHT_VERSION >= 2" > > 2. a scheme more like mcs/ uses, where we'll define > SILVERLIGHT_2 > > in 2.0 builds, SILVERLIGHT_2 and SILVERLIGHT_3 in 3.0 builds, > > etc. > > Anyone have an opinion on which one to use? > > > > I'm personally a fan of the mcs style, if its used consistently > (another of our problems) its very easy to scan/parse what code is in what > build. Parsing a (>)(<)(=) # is a few extra cycles. > I like the mcs style too, but it gets somewhat convoluted when you have for instance 1.0, 2.0 and 3.0 and want to include only 2.0 features (SILVERLIGHT_2_ONLY). This will be a moot point if we branch when releasing new versions though, and in any case some time will pass until we get to this point :) Rolf > but thats just me > > -g > > > _______________________________________________ > Moonlight-list mailing list > Moonlight-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/moonlight-list > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.2.0/1495 - Release Date: > 10/06/2008 17:11 From ceronman at gmail.com Sat Jun 21 00:30:16 2008 From: ceronman at gmail.com (=?ISO-8859-1?Q?Manuel_Alejandro_Cer=F3n_Estrada?=) Date: Fri, 20 Jun 2008 23:30:16 -0500 Subject: [Moonlight-list] Using a Downloader from Gtk App. Message-ID: <796874fc0806202130h490c3ed6x53f1c8aa4ec2264d@mail.gmail.com> Hello. I want to create an Image control for my GtkSilver application. I'm doing something like: Image image = new Image(); image.Stretch = Stretch.Fill; image.Width = 100; image.Height = 100; Downloader downloader = new Downloader(); downloader.Completed += delegate { image.SetSource(downloader, null); }; downloader.Open("GET", new Uri("file:///home/ceronman/photo.png")); downloader.Send(); canvas.Children.Add(image); But the image is never shown and I'm getting this warning: (LunarEclipse:22160): Moonlight-WARNING **: Downloader::Send (): No surface! I believe this problem is related to the AllowMultipleSurfacesPerDomain issue I mentioned [1] before. But I have no idea how to solve it this time. I've seen the code of the LightTable extension to F-Spot and it apparently uses the same mechanism . Any Idea? [1] http://lists.ximian.com/pipermail/moonlight-list/2008-April/000022.html Manuel. From rolflists at ya.com Sat Jun 21 05:10:12 2008 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Sat, 21 Jun 2008 11:10:12 +0200 Subject: [Moonlight-list] Using a Downloader from Gtk App. In-Reply-To: <796874fc0806202130h490c3ed6x53f1c8aa4ec2264d@mail.gmail.com> References: <796874fc0806202130h490c3ed6x53f1c8aa4ec2264d@mail.gmail.com> Message-ID: <007b01c8d37e$9d9fe160$d8dfa420$@com> Hi, > Hello. > > I want to create an Image control for my GtkSilver application. I'm > doing something like: > > Image image = new Image(); > image.Stretch = Stretch.Fill; > image.Width = 100; > image.Height = 100; > Downloader downloader = new Downloader(); There's a method on the surface (Surface::CreateDownloader) which has to be called to create a downloader in this case. Unfortunately there's no managed binding / helper methods to do this yet. We have to add a C-binding to Surface::CreateDownloader, and a helper method in managed code which calls this C-binding to create a native downloader. Then just use the internal Downloader (IntPtr) ctor to create a managed downloader and return that from the helper method. Rolf > downloader.Completed += delegate { > image.SetSource(downloader, null); > }; > downloader.Open("GET", new Uri("file:///home/ceronman/photo.png")); > downloader.Send(); > > canvas.Children.Add(image); > > But the image is never shown and I'm getting this warning: > > (LunarEclipse:22160): Moonlight-WARNING **: Downloader::Send (): No > surface! > > I believe this problem is related to the > AllowMultipleSurfacesPerDomain issue I mentioned [1] before. But I > have no idea how to solve it this time. > > I've seen the code of the LightTable extension to F-Spot and it > apparently uses the same mechanism . > > Any Idea? > > [1] http://lists.ximian.com/pipermail/moonlight-list/2008- > April/000022.html > > Manuel. > _______________________________________________ > Moonlight-list mailing list > Moonlight-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/moonlight-list > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.4.1/1510 - Release Date: > 19/06/2008 15:21 From stephane at delcroix.org Mon Jun 23 18:03:29 2008 From: stephane at delcroix.org (Stephane Delcroix) Date: Tue, 24 Jun 2008 00:03:29 +0200 Subject: [Moonlight-list] [PATCH] Changes to the downloader, need review Message-ID: <1214258609.3427.17.camel@dogbert.home> Guys, In order to implement SL2.0 WebClient/WebRequest/WebResponse, I needed soemm changes in the plugin as the SL1.0 browser_http_get_request were removed some time ago. Per Geoff request, I moved all the Browser[Request|Response] stuffs to libmoon (renamed Downloader[Request|Response]) and added a initialization function for the plugin. I know we're more focused on fixing 1.0 than pushing new code for 2.0, but I'd like to have this one included anyway. As this patch touches various part of the code (moon/plugin/downloader) please let me know if you have a strong opposition against it regards s From stephane at delcroix.org Mon Jun 23 18:16:47 2008 From: stephane at delcroix.org (Stephane Delcroix) Date: Tue, 24 Jun 2008 00:16:47 +0200 Subject: [Moonlight-list] [PATCH] Changes to the downloader, need review In-Reply-To: <1214258609.3427.17.camel@dogbert.home> References: <1214258609.3427.17.camel@dogbert.home> Message-ID: <1214259407.3427.19.camel@dogbert.home> this time with the patch s On Tue, 2008-06-24 at 00:03 +0200, Stephane Delcroix wrote: > Guys, > > In order to implement SL2.0 WebClient/WebRequest/WebResponse, I needed > soemm changes in the plugin as the SL1.0 browser_http_get_request were > removed some time ago. > > Per Geoff request, I moved all the Browser[Request|Response] stuffs to > libmoon (renamed Downloader[Request|Response]) and added a > initialization function for the plugin. > > I know we're more focused on fixing 1.0 than pushing new code for 2.0, > but I'd like to have this one included anyway. > > As this patch touches various part of the code (moon/plugin/downloader) > please let me know if you have a strong opposition against it > > regards > > s > > _______________________________________________ > Moonlight-list mailing list > Moonlight-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/moonlight-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 23997 bytes Desc: not available Url : http://lists.ximian.com/pipermail/moonlight-list/attachments/20080624/807918ad/attachment-0001.bin From gnorton at novell.com Tue Jun 24 21:09:28 2008 From: gnorton at novell.com (Geoff Norton) Date: Tue, 24 Jun 2008 21:09:28 -0400 Subject: [Moonlight-list] [PATCH] Changes to the downloader, need review In-Reply-To: <1214259407.3427.19.camel@dogbert.home> References: <1214258609.3427.17.camel@dogbert.home> <1214259407.3427.19.camel@dogbert.home> Message-ID: <1214356168.5276.21.camel@limestone> Stephane, This looks generally ok to me, but I have a few comments: #1 in ?plugin_downloader_create_webrequest we should guard against a null instance. #2 I don't like the fact that we create requests on both sides, we should probably refactor p-d a little more to do all request creation/deletion/tracking in the downloader. Thoughts? -g On Tue, 2008-06-24 at 00:16 +0200, Stephane Delcroix wrote: > this time with the patch > > s > > On Tue, 2008-06-24 at 00:03 +0200, Stephane Delcroix wrote: > > Guys, > > > > In order to implement SL2.0 WebClient/WebRequest/WebResponse, I needed > > soemm changes in the plugin as the SL1.0 browser_http_get_request were > > removed some time ago. > > > > Per Geoff request, I moved all the Browser[Request|Response] stuffs to > > libmoon (renamed Downloader[Request|Response]) and added a > > initialization function for the plugin. > > > > I know we're more focused on fixing 1.0 than pushing new code for 2.0, > > but I'd like to have this one included anyway. > > > > As this patch touches various part of the code (moon/plugin/downloader) > > please let me know if you have a strong opposition against it > > > > regards > > > > s > > > > _______________________________________________ > > Moonlight-list mailing list > > Moonlight-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/moonlight-list > > > _______________________________________________ > Moonlight-list mailing list > Moonlight-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/moonlight-list From falls.huang at gmail.com Wed Jun 25 07:56:05 2008 From: falls.huang at gmail.com (falls huang) Date: Wed, 25 Jun 2008 19:56:05 +0800 Subject: [Moonlight-list] problem : can't compile the examples in moon Message-ID: <49eab5c80806250456na3170cy6a546b0996a165fb@mail.gmail.com> Hello! I downloaded moon from the head of the Subversion code repository, and configure it with: ./configure --enable-maintainer-mode --enable-compile-warnings --with-ffmpeg=no then I compile and install it in my suse linux 10. after the compile : 1. cd moon/examples/desklet/ruler/ 2. make it said: echo "#!/bin/sh" > example-ruler echo "mopen -d /usr/local/lib/desklets/example-ruler" >> example-ruler chmod +x example-ruler make: *** No rule to make target `../../../gtk/gtksilver.dll', needed by `ruler.dll'. Stop. then , I returned to the top directory of moonlight src , and execute : make -f Makefile -C gtk , it said: make: Entering directory `/home/falls/Desktop/moon/gtk' make: *** No rule to make target `../class/lib/3.0/Mono.Moonlight.dll', needed by `gtksilver.dll'. Stop. make: Leaving directory `/home/falls/Desktop/moon/gtk' What's wrong with it? I'm new to moonlight ,please pardon me for such a newbie problem :) -- Regards Falls Huang From stephane at delcroix.org Wed Jun 25 08:44:38 2008 From: stephane at delcroix.org (Stephane Delcroix) Date: Wed, 25 Jun 2008 14:44:38 +0200 Subject: [Moonlight-list] problem : can't compile the examples in moon In-Reply-To: <49eab5c80806250456na3170cy6a546b0996a165fb@mail.gmail.com> References: <49eab5c80806250456na3170cy6a546b0996a165fb@mail.gmail.com> Message-ID: <1214397878.3427.48.camel@dogbert.home> try passing --with-mono to autogen.sh s On Wed, 2008-06-25 at 19:56 +0800, falls huang wrote: > Hello! > > I downloaded moon from the head of the Subversion code repository, > and configure it with: > ./configure --enable-maintainer-mode --enable-compile-warnings --with-ffmpeg=no > > then I compile and install it in my suse linux 10. > > after the compile : > > 1. cd moon/examples/desklet/ruler/ > 2. make > it said: > echo "#!/bin/sh" > example-ruler > echo "mopen -d /usr/local/lib/desklets/example-ruler" >> example-ruler > chmod +x example-ruler > make: *** No rule to make target `../../../gtk/gtksilver.dll', needed > by `ruler.dll'. Stop. > > then , I returned to the top directory of moonlight src , and execute > : make -f Makefile -C gtk , it said: > > make: Entering directory `/home/falls/Desktop/moon/gtk' > make: *** No rule to make target > `../class/lib/3.0/Mono.Moonlight.dll', needed by `gtksilver.dll'. > Stop. > make: Leaving directory `/home/falls/Desktop/moon/gtk' > > What's wrong with it? > > I'm new to moonlight ,please pardon me for such a newbie problem :) > > -- > Regards > Falls Huang > _______________________________________________ > Moonlight-list mailing list > Moonlight-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/moonlight-list > From falls.huang at gmail.com Wed Jun 25 17:25:54 2008 From: falls.huang at gmail.com (falls huang) Date: Thu, 26 Jun 2008 05:25:54 +0800 Subject: [Moonlight-list] problem : can't compile the examples in moon In-Reply-To: <1214397878.3427.48.camel@dogbert.home> References: <49eab5c80806250456na3170cy6a546b0996a165fb@mail.gmail.com> <1214397878.3427.48.camel@dogbert.home> Message-ID: <49eab5c80806251425jb9be029vbb040e268edd7d3a@mail.gmail.com> Hello ! Thank u! After I upgraded my mono from 1.2 to 1.9.1 , the problem of configure disappeared. But... a new problem came out: 1. I configure moon(head of svn) with ./autogen.sh : ./configure --with-ffmpeg=no --with-mono=yes in the end, it printed: the following features: PNG functions: no (disabled, use --enable-png to enable) and the following debug options: gcov support: no test surfaces: no ps testing: no pdf testing: no svg testing: no using CFLAGS: -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/X11R6/include -I$(top_srcdir)/../pixman/pixman -Wall -Wextra -Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wdeclaration-after-statement -Wold-style-definition -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -fno-strict-aliasing Moonlight configuration: Support for 1.0: yes Support for 2.0: yes Support for ffmpeg: no Support for running the test harness: no Using cairo: embedded Support for Firefox: no With Silverlight 1.0 bugs: yes 2. then I use "make" to compile it , and I got an error: make[3]: Entering directory `/home/falls/study/moon-svn/class/Mono.Moonlight' MONO_PATH="../lib/2.1:$MONO_PATH" mono --runtime=moonlight --security=temporary-smcs-hack ../lib/2.1/smcs.exe /codepage:65001 -d:NET_1_1 -d:NET_2_0 -debug+ -noconfig -r:System -d:AGCLR -unsafe -target:library -out:../lib/2.1/Mono.Moonlight.dll ./../Consts.cs ./Assembly/AssemblyInfo.cs ./Mono/Kind.cs ./Mono/NativeMethods.cs ./Mono/Value.cs ./Mono/Moonlight.cs ./Mono/Helper.cs ./Mono/XamlLoaderCallbacks.cs ./Mono/XapHack.cs ./System.IO/SimpleUnmanagedMemoryStream.cs ./System.Windows.Interop/PluginHost.cs -d:NET_2_1 -keyfile:./../mono.snk ./Mono/Helper.cs(47,32): error CS0246: The type or namespace name `TypeConverter' could not be found. Are you missing a using directive or an assembly reference? Compilation failed: 1 error(s), 0 warnings Is the head of svn broken ? Should I use another stable version of moonlight ? btw: Would anyone plz tell me where can I download a binary of moonlight(with mopen command) ? 2008/6/25, Stephane Delcroix : > try passing --with-mono to autogen.sh > > s > > > On Wed, 2008-06-25 at 19:56 +0800, falls huang wrote: > > Hello! > > > > I downloaded moon from the head of the Subversion code repository, > > and configure it with: > > ./configure --enable-maintainer-mode --enable-compile-warnings --with-ffmpeg=no > > > > then I compile and install it in my suse linux 10. > > > > after the compile : > > > > 1. cd moon/examples/desklet/ruler/ > > 2. make > > it said: > > echo "#!/bin/sh" > example-ruler > > echo "mopen -d /usr/local/lib/desklets/example-ruler" >> example-ruler > > chmod +x example-ruler > > make: *** No rule to make target `../../../gtk/gtksilver.dll', needed > > by `ruler.dll'. Stop. > > > > then , I returned to the top directory of moonlight src , and execute > > : make -f Makefile -C gtk , it said: > > > > make: Entering directory `/home/falls/Desktop/moon/gtk' > > make: *** No rule to make target > > `../class/lib/3.0/Mono.Moonlight.dll', needed by `gtksilver.dll'. > > Stop. > > make: Leaving directory `/home/falls/Desktop/moon/gtk' > > > > What's wrong with it? > > > > I'm new to moonlight ,please pardon me for such a newbie problem :) > > > > -- > > Regards > > Falls Huang > > > _______________________________________________ > > Moonlight-list mailing list > > Moonlight-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/moonlight-list > > > > -- Regards Falls Huang From gnorton at novell.com Mon Jun 30 17:17:29 2008 From: gnorton at novell.com (Geoff Norton) Date: Mon, 30 Jun 2008 17:17:29 -0400 Subject: [Moonlight-list] Moonlight-bugs list Message-ID: <1214860649.5276.88.camel@limestone> Hey all, I've created a new list (moonlight-bugs at lists.ximian.com) at the request of Rusty. In the near future all moonlight bugs emails will be moved there so you likely want to subscribe now. If you have any problems please email me directly. -g