20110929T015043: *: <== :aivar!~aivar@dyn-144-92-48-238.microscopy.wisc.edu QUIT :Quit: aivar 20110929T094226: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu JOIN #imagejdev 20110929T102847: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu QUIT :Quit: hinerm 20110929T132100: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu JOIN #imagejdev 20110929T145206: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com JOIN #imagejdev 20110929T155431: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :FYI, for those developing on Mac OS X or Windows, there was a case change for a file called ImgLibDataTransform.java. If you update, you may experience some weirdness. Deleting the file and then updating again should resolve it. 20110929T155534: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: FYI, for those developing on Mac OS X or Windows, there was a case change for a file called ImgLibDataTransform.java. If you update, you may experience some weirdness. Deleting the file and then updating again should resolve it. 20110929T155930: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com QUIT :Quit: Leaving. 20110929T161155: *: <== :aivar!~aivar@dyn-144-92-48-238.microscopy.wisc.edu JOIN #imagejdev 20110929T162030: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com JOIN #imagejdev 20110929T172209: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu QUIT :Quit: hinerm 20110929T172818: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu JOIN #imagejdev 20110929T183118: *: <== :hinerm!~hinerm@dyn-144-92-48-204.microscopy.wisc.edu QUIT :Quit: hinerm 20110929T193305: *: <== :afraser!~afraser@c-75-67-186-216.hsd1.ma.comcast.net JOIN #imagejdev 20110929T205401: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Hi all. A quick update on what I am working on: I am looking to refactor the display hierarchy to eliminate the UI-specific SwingDatasetView and SwingOverlayView classes. The logic they provide will definitely be preserved in the codebase somewhere, but the motivation for the change is that a "DataView" was originally conceived as a UI-agnostic bag of display settings for a Data object. 20110929T205401: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Hi all. A quick update on what I am working on: I am looking to refactor the display hierarchy to eliminate the UI-specific SwingDatasetView and SwingOverlayView classes. The logic they provide will definitely be preserved in the codebase somewhere, but the motivation for the change is that a "DataView" was originally conceived as a UI-agnostic bag of display settings for a Data object. 20110929T205424: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :This will make implementing plugins that need to output DataViews much easier. 20110929T205424: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: This will make implementing plugins that need to output DataViews much easier. 20110929T205448: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Or rather, it will make them UI-agnostic, as they need to be, without adding any potentially clunky DataView factory logic anywhere. 20110929T205448: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Or rather, it will make them UI-agnostic, as they need to be, without adding any potentially clunky DataView factory logic anywhere. 20110929T205527: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :I think all the Swing-specific stuff can be wrapped into SwingImageDisplay and related helper classes. So the Swing-specific stuff from SwingDatasetView and SwingOverlayView might end up in one or more SwingDataDisplayLink classes or some such—still working through it. 20110929T205527: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: I think all the Swing-specific stuff can be wrapped into SwingImageDisplay and related helper classes. So the Swing-specific stuff from SwingDatasetView and SwingOverlayView might end up in one or more SwingDataDisplayLink classes or some such—still working through it. 20110929T205659: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :As part of this refactoring, I want the Display.update() method to really be a workhorse for updating the display onscreen, including any pending structural changes / rebuilds that need to occur. That is, displays should keep track of when/how their constituent data objects change, but not update themselves until update() is called. This allows API users to do things like add multiple objects without it triggering an automatic upda 20110929T205659: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: As part of this refactoring, I want the Display.update() method to really be a workhorse for updating the display onscreen, including any pending structural changes / rebuilds that need to occur. That is, displays should keep track of when/how their constituent data objects change, but not update themselves until update() is called. This allows API users to do things like add multiple objects without it triggering an automatic upda 20110929T205825: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Once I get the above sorted, next steps are: 20110929T205825: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Once I get the above sorted, next steps are: 20110929T205827: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :A) reevaluate how DisplayPanel and DisplayWindow fit in to the hierarchy—e.g., there is currently some wonkiness with display logic delegating to the panel and/or the window. It would be good to have a clear hierarchy and execution flow between these classes, and a clean dependency hierarchy as well with respect to them. 20110929T205827: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: A) reevaluate how DisplayPanel and DisplayWindow fit in to the hierarchy—e.g., there is currently some wonkiness with display logic delegating to the panel and/or the window. It would be good to have a clear hierarchy and execution flow between these classes, and a clean dependency hierarchy as well with respect to them. 20110929T205949: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :B) remove as much Dataset- and Overlay-specific logic from the ImageDisplay code as possible, generalizing it to Data code and so on. This is in preparation for the addition of a CompositeData or DataList or similar that will be a tuple of multiple Data objects, allowing the construction of tree structures of data. This will let us model things like mosaics consisting of tiles, clearly delineate which overlays belong to which datas 20110929T205949: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: B) remove as much Dataset- and Overlay-specific logic from the ImageDisplay code as possible, generalizing it to Data code and so on. This is in preparation for the addition of a CompositeData or DataList or similar that will be a tuple of multiple Data objects, allowing the construction of tree structures of data. This will let us model things like mosaics consisting of tiles, clearly delineate which overlays belong to which datas 20110929T210013: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :(B) is really the essence of ticket 660, but the rest of the above all goes with it too, for better or for worse. I could split these things into multiple tickets, I suppose. 20110929T210013: *: ==> PRIVMSG #imagejdev :Ticket 660 can be found here: http://dev.imagejdev.org/trac/imagej/ticket/660 20110929T210013: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: (B) is really the essence of ticket 660, but the rest of the above all goes with it too, for better or for worse. I could split these things into multiple tickets, I suppose. 20110929T210059: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :That was more text than I expected to write… perhaps I should send an email to the mailing list with the above summary, or else make a blog post. I think I'll do the latter. 20110929T210059: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: That was more text than I expected to write… perhaps I should send an email to the mailing list with the above summary, or else make a blog post. I think I'll do the latter. 20110929T210950: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Blog entry posted: http://imagejdev.org/2011/09/29/display-framework-changes 20110929T210950: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Blog entry posted: http://imagejdev.org/2011/09/29/display-framework-changes 20110929T211022: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Now I have to go take care of a few things, so I will talk to y'all later. Tomorrow will largely be occupied with MathBio3, but hopefully I can get some work done on ImageJ during the talks. 20110929T211022: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Now I have to go take care of a few things, so I will talk to y'all later. Tomorrow will largely be occupied with MathBio3, but hopefully I can get some work done on ImageJ during the talks. 20110929T211025: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com PRIVMSG #imagejdev :Ciao. 20110929T211025: ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com: Ciao. 20110929T211120: *: <== :ctrueden!~Adium@66-188-99-35.dhcp.mdsn.wi.charter.com QUIT :Quit: Leaving. 20110929T213130: *: <== :afraser!~afraser@c-75-67-186-216.hsd1.ma.comcast.net QUIT :Quit: afraser 20110929T214344: *: <== :afraser!~afraser@c-75-67-186-216.hsd1.ma.comcast.net JOIN #imagejdev 20110929T235051: *: <== :afraser!~afraser@c-75-67-186-216.hsd1.ma.comcast.net QUIT :Quit: afraser