Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [riena-dev] RienaDialog / DialogView suggestions 
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:
cons DialogView() {
  super(null != parent ? parent.getShell()
     : Display.getDefault().getActiveShell());
                    ^^^^^^^ bad - avoid !!!

The Display.getDefault() will make the thread that constructs the
DialogView the UI thread - if there is no UI thread already.

One should try to never to use Display.getDefault() (exception:
snippets and SWT only apps). Instead widget.getDisplay() or
PlatformUI.getWorkbench().getDisplay() should be called. Actually
workbench.getDisplay() mentions this in the java doc :-).

Also normally the UI thread should always be constructed in your / our
Application.createView():

createView() {
        // makes this thread the UI thread
	Display display = PlatformUI.createDisplay();
        // blocks this thread until exit and processes UI events in a while-loop
        int returnCode = PlatformUI.createAndRunWorkbench(display, advisor);
}

Let's discuss what can be done on 287617.

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
>
>



-- 
Elias Volanakis | Technical Lead | EclipseSource Portland
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com

Back to the top