Re: Weird issues reading pixels of jpg file on osx

Thanks Dan,

I've opened bug #79246 for the LockBits issues which, from the unit
tests I added this morning, appears to affect every type of bitmaps.

FYI the problem that affected the (first two lines of) JPEG bitmaps
doesn't happen on any other type of pictures.

On Thu, 2006-08-31 at 09:02 -0700, Dan Shryock wrote:
> Sebastien,
> 
> I just ran the code for reading jpegs on the 1.1.14 build on osx and
> it had different results that those that I am currently getting, but
> they were still not correct.  Hope this helps.
> 
> Dan
> 
> On 1.1.14 it came out as:
> 
> 255
> 255
> 255
> 255
> 77
> 255
> 255
> 75
> 144
> 255
> 75

Mono Winforms Team: we are hiring.

Hello,

    We are looking for some strong developers interested in joining the
Mono Windows Forms team at Novell.   

    What we are looking for:

	* Win32 and/or X11 experience;

	* GUI programming experience.

	* Desire to implement lots of new widgets.

	* Boston-based would be best, but we do not mind remote
	  hiring, provided you are a good communicator on email,
	  and can use irc to discuss and are in close contact
	  with your manager.

	* You must be able to show that you can write code, so if you 
	  can show us code you have written before, or point us to
	  projects you have worked on, or have good references about
	  your coding abilities, all the better.

	* C# and C knowledge are a must.

	* If you have ever used a decompiler to look at Microsoft.NET
	  code you can not apply.

Miguel.
_______________________________________________

Re: [Mono-dev] Mono Winforms Team: we are hiring.

Hello,

    I forgot to say: email your resumes to miguel <at> ximian.com

> Hello,
> 
>     We are looking for some strong developers interested in joining the
> Mono Windows Forms team at Novell.   
> 
>     What we are looking for:
> 
> 	* Win32 and/or X11 experience;
> 
> 	* GUI programming experience.
> 
> 	* Desire to implement lots of new widgets.
> 
> 	* Boston-based would be best, but we do not mind remote
> 	  hiring, provided you are a good communicator on email,
> 	  and can use irc to discuss and are in close contact
> 	  with your manager.
> 
> 	* You must be able to show that you can write code, so if you 
> 	  can show us code you have written before, or point us to
> 	  projects you have worked on, or have good references about
> 	  your coding abilities, all the better.
> 
> 	* C# and C knowledge are a must.
> 
> 	* If you have ever used a decompiler to look at Microsoft.NET

Extended error reporting for libgdiplus/System.Drawing

Ever since I started working on libgdiplus and the related System.Drawing
bits, I've always been somewhat unimpressed by the error reporting
capabilities of GDI+. I didn't think it would be too hard to make them a
lot better, even without breaking cross-platform compatibility, but I
didn't have the free time to sit down and work it out until now.

My proposal is two added functions to libgdiplus, along with a new GpStatus
value.

  GpStatus.ExtendedError (1000000): Indicates that the last error which
    occurred has an extended description accessible through
    GdipGetErrorEx ().

  GpStatus GdipSetErrorEx (GpStatus status, char *description): Places
    the specified status code & description into TLS slots allocated
    for the purpose and returns GpStatus.ExtendedError. In the event
    that TLS slots could not be allocated (a non-fatal error during
    GdipStartup ()), GdipSetErrorEx actually simply returns its first
    argument, and the feature is transparently disabled.

  int GdipGetErrorEx (GpStatus *status, char *description): Copies the
    last error set with GdipSetErrorEx into the parameters. Either
    parameter can be NULL. If description is not NULL, then it is
    assumed to be large enough to store the string. The caller
    determines this size by first calling the function with a NULL
    pointer for description; the return value is the necessary number
    of bytes (including null-terminator) for the buffer.

This extended error status code (GpStatus.ExtendedError) is then detected
in the System.Drawing side. Of course, we would break compatibility if we

Re: Extended error reporting for libgdiplus/System.Drawing

Hello Jonathan,

On Mon, 2006-09-04 at 17:57 -0500, Jonathan Gilbert wrote:
> Ever since I started working on libgdiplus and the related System.Drawing
> bits, I've always been somewhat unimpressed by the error reporting
> capabilities of GDI+. 

True, still very similar to most of the Win32 API 

> I didn't think it would be too hard to make them a
> lot better, even without breaking cross-platform compatibility, but I
> didn't have the free time to sit down and work it out until now.
> 
> My proposal is two added functions to libgdiplus, along with a new GpStatus
> value.
> 
>   GpStatus.ExtendedError (1000000): Indicates that the last error which
>     occurred has an extended description accessible through
>     GdipGetErrorEx ().
> 
>   GpStatus GdipSetErrorEx (GpStatus status, char *description): Places
>     the specified status code & description into TLS slots allocated
>     for the purpose and returns GpStatus.ExtendedError. In the event
>     that TLS slots could not be allocated (a non-fatal error during
>     GdipStartup ()), GdipSetErrorEx actually simply returns its first
>     argument, and the feature is transparently disabled.
> 
>   int GdipGetErrorEx (GpStatus *status, char *description): Copies the
>     last error set with GdipSetErrorEx into the parameters. Either
>     parameter can be NULL. If description is not NULL, then it is

[2.0 Patch] FlowLayoutPanel Implementation

Attached is an implementation of SWF 2.0's FlowLayoutPanel and some 
related tests.

DefaultLayout.cs, FlowLayout.cs: Initial commit.
FlowLayoutPanel.cs: Initial commit.
Control.cs:
    Add properties: LayoutEngine, Margin, DefaultMargin.
    Add method: GetPreferredSize.
    Move layout logic from PerformLayout to layout engines.

FlowPanelTests.cs: Initial commit.

There should not be any changes outside of NET_2_0 defines.

Please review and approve, especially the changes to Control.cs.

Thanks.
jpobst

_______________________________________________
Mono-winforms-list maillist  -  Mono-winforms-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Re: [Mono-dev] Extended error reportingforlibgdiplus/System.Drawing

At 08:51 AM 05/09/2006 -0400, Sebastien Pouliot wrote:
>Hello Jonathan,
>
>On Mon, 2006-09-04 at 17:57 -0500, Jonathan Gilbert wrote:
>> Ever since I started working on libgdiplus and the related System.Drawing
>> bits, I've always been somewhat unimpressed by the error reporting
>> capabilities of GDI+. 
>
>True, still very similar to most of the Win32 API 

Well yes, except that the Win32 API typically does not do a great deal in
any given function call, whereas GDI+ has many layers & modules which can
be involved in a single call (e.g. GdipLoadImageFromStream).

For instance, while loading a BMP file, if the stream is cut off early (or
in fact if any partial fread() occurs), the error code returned will be
InvalidParameter, to indicate that the filename provided refers to an
invalid file. At present, this will be turned into an exception of type
ArgumentException with message:

  Invalid Parameter. A null reference or invalid value was found.

This really doesn't convey what actually went wrong, and with extended
error reporting, the code which currently does:

  status = InvalidParameter;

..could be changed to something like:

  status = GdipSetErrorEx(InvalidParameter, "Unexpected end-of-file while

Re: Mono Winforms Team: we are hiring.

> 	* C# and C knowledge are a must.

Do you use simple C or C++ ? And what percent of code of SWF controls do 
you ofter write on C?

_______________________________________________
Mono-list maillist  -  Mono-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: Mono Winforms Team: we are hiring.

On Tue, 2006-09-05 at 11:46 +0300, sasha wrote:
> > 	* C# and C knowledge are a must.
> 
> Do you use simple C or C++ ?

C.  All C code is within a support library invoked by C# through
P/Invoke, and thus needs to export a C ABI.  (C++ with ``extern "C"''
could be used as well, but C is the currently chosen language for a
number of reasons.)

> And what percent of code of SWF controls do 
> you ofter write on C?

Most of the SWF controls are C#.  I imagine that the "C knowledge" is
for two things:

  - Understanding the underlying X11/Win32 API, so that appropriate
    P/Invoke declarations can be written.

  - Writing the MonoSupportW library, which has several helper routines
    for non-Win32 platforms implementing Win32 API calls.  The 
    MonoSupportW source is in the `mono' svn module, in the `support'
    directory (support.c & support-heap.c).

 - Jon

_______________________________________________
Mono-list maillist  -  Mono-list <at> lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono Winforms Team: we are hiring.

>Most of the SWF controls are C#.  I imagine that the "C knowledge" is
>for two things:
>
>  - Understanding the underlying X11/Win32 API, so that appropriate
>    P/Invoke declarations can be written.
>
>  - Writing the MonoSupportW library, which has several helper routines
>    for non-Win32 platforms implementing Win32 API calls.  The
>    MonoSupportW source is in the `mono' svn module, in the `support'
>    directory (support.c & support-heap.c).
Actually, we don't (yet) work on that. And, the idea of that lib is to 
reflect calls back to managed code (the Win32 calls we will emulate will be 
written in C#)

The reason C knowledge is needed is because our libgdiplus library is 
written in C. Libgdiplus is used by System.Drawing to draw our controls, but 
the code implementing the controls is C#.

Peter