[Mono-dev] Mono Winforms on Mac

Ralph Leckett rleckett at gmail.com
Wed Nov 10 21:42:07 EST 2010


My apologies but I am currently occupied with the matter of finding a job.
My changes are there and they do fix quite a number of problems with
Mac Mono Winforms.
Do with them as you will.

Ralph


On 11/10/10, Miguel de Icaza <miguel at novell.com> wrote:
> Hello Ralph,
>
>     I wanted to follow up to see if you had a chance of providing us a
> roadmap of the changes that you did for Winforms.   As I mentioned on my
> post with the cleaned up patch, there are some bits that are not
> controversial, but still need to be reviewed and others that are hard to see
> what the changes was supposed to do.
>
>     Perhaps you could review the cleaned up patch that I sent and send us
> patches/changes in individual pieces with the functionality isolated for
> review and merging?
>
> Miguel
>
> On Sat, Oct 30, 2010 at 3:10 PM, Ralph Leckett <rleckett at gmail.com> wrote:
>
>> Does the Mono Project have it's own format utility? It would be nice
>> to make all the code consistent no matter what that format is.
>>
>> On 10/30/10, Miguel de Icaza <miguel at novell.com> wrote:
>> > Hello Ralph,
>> >
>> >     Have you given any consideration to providing a roadmap to your
>> changes
>> > so that they can be individually reviewed?
>> >
>> >     Since you reformatted the source code, it is not possible to apply
>> the
>> > patches directly, we still have to apply every change by hand and it
>> would
>> > be useful to have the different patches and changes reviewed
>> independently.
>> >
>> > Miguel
>> >
>> > On Sat, Oct 30, 2010 at 10:34 AM, Ralph Leckett <rleckett at gmail.com>
>> wrote:
>> >
>> >> Attached is another set of updates for Mac Mono Winforms. My .net
>> >> applications now work quite nicely with my changes to Mono.
>> >>
>> >> NativeWindow has been simplified to using Hwnd to provide the
>> >> Handle-Window lookup. I have found that storing handles in Hashtable
>> >> sometimes results in the handle being lost with the result being
>> >> zombie windows. Replacing Hashtable with a linked list solved the
>> >> problem. Placing the most recently used link at the head of the linked
>> >> list maintains efficiency.
>> >>
>> >> MS Windows places paint events at the lowest priority with all other
>> >> events preempting WM_PAINT. A separate queue (linked list in my case)
>> >> for paint events is required for Mono to duplicate this effect.
>> >>
>> >> I find the exposure of method variables to outside objects without
>> >> using properties to be one of the poorer coding practices used in
>> >> Mono. Apart from that, I found Mono to be quite well written and a
>> >> pleasure to work on.
>> >>
>> >> Ralph
>> >>
>> >> On 10/20/10, Ralph Leckett <rleckett at gmail.com> wrote:
>> >> > The namespaces in the code caused compile errors in one of my test
>> >> > environments so I had to remove them.
>> >> >
>> >> > Attached is an update to my updates to fix this problem:
>> >> > https://bugzilla.novell.com/show_bug.cgi?id=438281
>> >> >
>> >> > Ralph
>> >> >
>> >> > On 10/19/10, Miguel de Icaza <miguel at novell.com> wrote:
>> >> >> Hello,
>> >> >>
>> >> >>     I have created a diff file from the formatted sources that
>> removes
>> >> >> some of the other automatic changes that probably came out of some
>> >> >> refactoring tool.   The patch itself can not be used directly
>> >> >> against
>> >> >> Mono's source code since it is still a diff from formatted to
>> >> >> formatted,
>> >> >> not from Mono to formatted.    This means that we are going to have
>> to
>> >> >> apply every patch by hand.
>> >> >>
>> >> >>     I personally like the changes that were made by the tool, like
>> >> >> dropping the gratuitous overuse of namespaces in the
>> >> >> Managed.Winforms
>> >> >> code, and would love to plug those changes back in the future.
>> >> >>
>> >> >>     In terms of how to get the changes merged, ideally, Ralph could
>> >> >> review the attached file and provide a roadmap of what each of the
>> >> >> changes do.   There are some that I suspect wont be controversial,
>> for
>> >> >> example:
>> >> >>
>> >> >>      * There is a refactoring of the Clipboard code, this seems
>> >> >>        straightforward, but it still needs a review.
>> >> >>
>> >> >>      * Some look like simple bug fixes, but it would be good to
>> >> >>        know what were they fixing (for example the ListView.cs
>> >> >>        changes).
>> >> >>
>> >> >>     There are other pieces that look like they went through a lot of
>> >> >> work, and a more detailed explanation of the changes would be
>> >> >> useful,
>> >> >> in
>> >> >> this group, I would include:
>> >> >>
>> >> >>      * Hwnd.cs
>> >> >>
>> >> >>      * XplatUICarbon.cs
>> >> >>
>> >> >>     There are some that probably we can skip, like the
>> >> >> System.Drawing
>> >> >> tracing facility.
>> >> >>
>> >> >>      The cleaned up patch is here:
>> >> >>
>> >> >>      http://tirania.org/tmp/changes.gz
>> >> >>
>> >> >>      This is the diffstat.  aNot sure how to deal with this, perhaps
>> >> >> with a Google doc, where we can use colors to flag what is applied
>> and
>> >> >> what not?   Or perhaps we remove parts of the patch when we have
>> >> >> manually applied that bit?
>> >> >>
>> >> > <snip>
>> >> >
>> >>
>> >
>>
>


More information about the Mono-devel-list mailing list