On 7 Feb 2009, at 5:17 AM, Adam R. Maxwell wrote: > > On Feb 6, 2009, at 11:08 AM, Christiaan Hofman wrote: > >> >> On 6 Feb 2009, at 7:40 PM, Maxwell, Adam R wrote: >> >>> On 02/06/09 07:18, "Christiaan Hofman" <cmhof...@gmail.com> wrote: >> >>>> It would be quite a bit of work, but I >>>> think it's doable. And it can be done in 3 steps. I already think >>>> I've >>>> a pretty good view of what should be done to remove OmniAppKit, >>>> including a replacement for the preferences. >>> >>> I have a few suggestions: >>> >>> 1) create a branch (duh) >> >> Merging in using SVN is a bit of a mess. But sure, especially as it >> would probably take a while. > > Maybe it would be easier to create a branch for releases and rewrite > on the trunk. As long as they're segregated so releases can > progress in case of major problems...
And nightlies should be from the release branch? The next generation SCM like git and bazar really make all this much easier. Though I don't know too much about it, but it's certainly much more flexible than SVN. > What's release status anyway? Goldstein was asking about a release > a month or so ago, I thought... > I think we should be close to release. And there haven't been any problems reported with the latest nightlies. >> >>> 2) drop 10.4 support at the same time >>> 3) avoid incorporating bindings at the same time >>> >>> Dropping 10.4 lets you use the kit's source list table/outline views >>> instead >>> of the OAGradientTableView, and allows cleanup to proceed using for/ >>> in and >>> properties if desired. Dumping the Omni frameworks will also likely >>> introduce a bunch of regressions that are 10.4-specific, and >>> debugging those >>> will be a PITA. >> >> I think that's a separate issue. I don't really see sufficient >> reasons >> yet to drop 10.4 support. > > I mainly think of debugging. BD can no longer be compiled on 10.4, > and who still has a 10.4 system and is willing and able to run gdb? > Most of the current code was developed on 10.4 or at least tested > fairly extensively on it. It's my belief that the major rewrite > involved in removing the Omni frameworks will create various bugs > that'll be a bitch to track down, especially since some of them will > be specific to 10.4. > That's a good point, for example the new 10.5 API that Omni has overwritten for Tiger, there's quite a bit of that. Without Omni those won't be present anymore on Tiger. That also brings me to the point that I can't figure out if there's any deprecated code. Still don't know why. >>> Using bindings on a project that multiple people are developing is a >>> big >>> problem, IMO, because it's hard to see what's changed in a diff or >>> figure >>> out what the binding paths are. This kept me from working on the >>> BD2 test, >>> and also Skim, to some extent, as it became impossible to keep up >>> with >>> changes and reverse-engineer everything in IB to see how it worked. >>> >>> -- >>> adam >> >> >> On the other hand bindings can really clean things up. I like it much >> more than the annoying glue code. I would rather move things to >> bindings. But I understand your point. > > I know there are benefits to bindings (performance, less code), but > I'm not convinced that the savings in glue code is worthwhile, since > you can at least step through code in the debugger. IMNSHO, > bindings don't clean things up; they just hide the cruft so it's > harder to find. > OTH, as they're based on fixed and thoroughly tested code (I assume) there's less room for error because there's less custom code. > As a side note, I ran into a fun problem with TeX Live Utility, > using bindings to validate a toolbar item. I bound it to an > NSOperationQueue's operatio...@count path, and started seeing weird > crashes. Sprinkling NSParameterAsserts around revealed that > NSOperationQueue delivers its KVO notifications on arbitrary > threads, so its KVO compliance is useless for binding. Implementing > validateUserInterfaceItem: was more code, but much saner :). > > -- > Adam Good point. I can imagine this happens. I guess binding can only be done to properties that are only changed on the main thread. OTH, I'd also say that as always one should be careful to update UI on the main thread, and that's true just as well when using bindings, so i see this more as an extension of that principle. Christiaan ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
