Axel Simon <axel.si...@in.tum.de> writes: > Hi Andy, > > (let's move this to the -devel list.) > > On 18.04.2010, at 17:53, Andy Stewart wrote: >>> >>> I will do these changes over the weekend and will send out another >>> mail with the exact locations of the repositories. If you feel that >>> this all is a really bad idea (it certainly is a bad), then please >>> shout and maybe there is a better alternative. > > So, I'm on my way and your new bindings are already obliterated in > code.haskell.darcs. For anyone > having a copy of the repo, it should be possible to say 'darcs push' and, by > answering 'no' to all > patches, one should get a list of all patches that need to be obliterated in > the local repository. I see. I have some new patches for darcs, but I will waiting you finish those before move to next step. I think this is easier for you. :) > >> Axel, below is my plan: >> >> (1) Waiting you release cabal repository without my new patches. >> (2) Convert all sub-directory to cabaling format. >> (3) Review my new patches, and filter *simple* correct functions and push to >> main repository. >> (4) Build incorrect functions *fix list*, and correct those functions. >> (5) Update Gtk+ to 2.20 (Spinner widget is very useful...) >> >> Yes, some complicated functions is incorrect, but not mean all patches >> is incorrect, i think most functions is correct, because them generate >> by ApiGen, i just did diff work. >> >> And it's easier to fix my patches than build new patches. >> >> If you haven't time to fix incorrect functions, i do. >> >> Of course, i will let you check before i push to main repository. I will >> ask you if i don't know how to binding some complicated fucntions. > > I am still working on it since there has been a patch in October (!) where > you add functions to > Notebook. I can't obliterate that since there are too many other patches > depending on it. Thus, I'm > now working on checking these functions. Ok, thanks.
> >> BTW, for my *large* patches problem, you can use some TODO tool track >> all details in those large patches. >> I use Emacs Org-Mode track those details (http://orgmode.org/) >> Org-Mode make your life easier, you can try to use it. >> > > Yes, you first patches were very large which makes it quite difficult to > start (since you have to > fix so much at once). I've re-recorded some of the later patches. Every new patches is corresponding to sub-directory under `gtk2hs/gtk/Graphics/UI/Gtk` So patch is very large if have many modules in some sub-directory. I use Org-Mode track every detail of patches that which functions is finishe or not. > >> And *Index of new symbols* in Gtk+ Reference Manual will help us judge >> which functions is new. > > > My biggest worry is that you have changed the names of some existing > functions. I know that I argued > that signal names that clash between different modules should be prefixed, > but renaming should only > be done to signals that are newly bound or that have already clashed before. > In this way no user > programs can be broken. However, you changed the destroy signal of Object to > objectDestroy which > will definitely break programs. This is one example. The problem is that it > is very hard to tell > what other functions have been renamed that way without meticulously looking > at each line of a > patch. Sorry, i won't do that anymore. :( > > Another problem I've seen is that you've replaced (I think) the Attributes in > Pango to the code > generated by apiGen. The Attributes in Pango were carefully hand-written and > purposely made more > friendly to a Haskell programmer. I've also seen similar things happening in > GC (graphics > contexts). apiGen is only there to help, it's not right in all cases. I see. > > >> I have some spare time on next month. >> But i don't know what's your status exactly, then i can adjust my time on >> gtk2hs. >> >> Can you finish all cabal job in this month? > > Yes, I think I can finish the cabalized version of glib, cairo, pango and gtk > (possibly gio since > that belongs to the core packages as well). I would like to move all other > bindings to their own > repositories (except for the Gtk specific demos). Yes, gio should be core packages, because upstream Gtk+ team use gio in many new functions. Please give me a template that how to convert package to cabalized version, i can help you convert other bindings, then we can release next version of gtk2hs quickly. > > I'm sure we can work it out. Since your early patches are very big, I suggest > you try to apply my > small re-recorded patches that correspond to your last patches. Anything > with newForeignPtr_ is > bound to be wrong, so feel free to ask how to do the memory management in > cases where it's not > clear. For current situation, a stable cabalized version is most important, i have seen many many people in IRC said them can't install gtk2hs. After we release cablized version, i will check all my new patches, and build two lists: *simple functions list* and *complicated functions list* For *simple functions*, i will re-record them to small patches, and send patch to here let you check, if okay, we push to main repository. After we push all *simple functions* to main repository, then we correct *complicated funtions* slowly. After we finish above job, i will push my new patches (update Gtk+ 2.20) to here, have some new widgets are very useful (such as GtkSpinner). I hope we can finish above job in first week of May, if you have't time do this, i do, i will ask you question how to do the memory management. In the future, we can perfect ApiGen or build new back-end that base on "gobject introspection". Thank you very much for your hard work. :) -- Andy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
