| Re: [riena-dev] RienaDialog / DialogView suggestions |
Elias Volanakis schrieb:
thx Elias,I think the original issue would be more approriate to discuss this: 287617 DialogView breaks API on setController (I'm adding your and my comments there) ;-)In short: The problem is that we tried to make Riena too smart for our own good:
...while skyping with flo, we thought, thatDisplay.getDefault().getActiveShell() is the reason. ... thanks for your great explanation ekke Kind regards, Elias. On Fri, Sep 18, 2009 at 6:44 AM, ekke <ekke@xxxxxxxxxxxxxxxx> wrote:Elias Volanakis schrieb: I've created Bug 289804 to continue the discussion there. Please add yourself if you're interested. http://bugs.eclipse.org/289804 I'm working on this for the current sprint. Flo just tried to make 1.2.0M1 run with changed DialogView, because the redView - CDO - integration is delayed - we have to wait for better fetching strategy now we got all with 1.2M1 compiled :-) ... but running the rcp app he now got thread exceptions. I put it into the bug above - excuse me if it was the wrong one, because perhaps the reason is not the changed DialogView. from tomorrow flo is one week on vacation - its perhaps never a good idea to try to change some things the last day ;-) but I forced him to try this because I wanted to use 1.2.M1 and then start working using bundles from HEAD ekke Elias. On Fri, Aug 21, 2009 at 6:10 AM, ekke <ekke@xxxxxxxxxxxxxxxx> wrote: sounds great ekke Christian Campo schrieb: I think having only one class to deal with would be a good think. I think breaking the API in the timeframe for Riena 1.2. is something we should either not do or be very cautious. I agree that everyone would a dialog to have look an feel and V/C support. So I would rather go down a path where we create a new class say RienaDialogView and we deprecate existing classes to make clear which path people should follow. So I agree with 2., 3. sounds good to me and 4. as well. Still under that precondition that we dont break API. So I rather not "move" or "rename" a method but create a new one (that we think has to more appropriate name) and deprecate the old one. 5. ok 6. I am not sure sure that every Dialog has an OK and Cancel button. Furthermore I am not sure that you could predict where they are located on the View. So I would rather step away from that. Its always easy for people to create a subclass for the View part that creates an OK and Cancel button. 7. agreed Constructor and setTitle christian Am 21.08.2009 um 01:10 schrieb Elias Volanakis: Here are a couple of ideas and suggestions that would make RienaDialog / DialogView easier to use from my POV (with API changes): 1. RienaDialog should not be API. -- I suggest making it package public. it only adds look-n-feel support 2. Rename RienaDialog (adds LnF support) to AbstractThemableDialog and DialogView (adds View/Controller) to RienaDialog -- I can't think why anybody would not want LnF support and V/C support. That means that most people would extends DialogView. I thnk renaming it to RienaDialog would be more intuitive. 3. Deprecate dialogView.build() in favor of dialogView.open() -- this is the standard call to open a dialog in Eclipse 4. Rename DialogView.buildView() to DialogView.basicCreatePartControl - this is the method where we create the UI in regular views; more similar naming 5. buildView() could be abstract, so that there is an obvious hint that somebody extending DialogView needs to implement this method (might cause problems with WindowBuilder though...) 6. Create OK and Cancel buttons by default -- currently everybody extending DialogView has to create his own buttons and buttonRidgets. This does not make sense to me. We should make the common case easy by creating Ok, Cancel buttons and invoking addUIControl(...) for them. This could happen in a protected method so it can be overwritten by people needing other buttons 7. I could not find an easy way to set the dialog title. If there is one please let me know -- ideally it should be something like dialogView.setTitle(...) or maybe even a constructor parameter Looking forward to your feedback. Kind regards, Elias. -- Elias Volanakis | Technical Lead | EclipseSource Portland elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com _______________________________________________ riena-dev mailing list riena-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/riena-dev _______________________________________________ riena-dev mailing list riena-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/riena-dev -- ekke (ekkehard gentz) independent software-architect senior erp-consultant eclipse | osgi | equinox | mdsd | oaw | emf | uml max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke@xxxxxxxxxxxxxxxx homepage (de): http://gentz-software.de blog (en): http://ekkes-corner.org twitter: @ekkescorner skype: ekkes-corner Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 _______________________________________________ riena-dev mailing list riena-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/riena-dev -- ekke (ekkehard gentz) independent software-architect senior erp-consultant eclipse | osgi | equinox | mdsd | oaw | emf | uml max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke@xxxxxxxxxxxxxxxx homepage (de): http://gentz-software.de blog (en): http://ekkes-corner.org twitter: @ekkescorner skype: ekkes-corner Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 _______________________________________________ riena-dev mailing list riena-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/riena-dev --
ekke (ekkehard gentz) |