Hi Alex,
Paul Webster
Eclipse Platform UI Committer
IBM Rational Canada
platform-ui-dev-bounces@xxxxxxxxxxx wrote on
09/22/2013 03:42:31 PM:
> Subject: [platform-ui-dev] Need help with bug 107346
>
>
> 1) Currently everything is in org.eclipse.workbench.ui.
Is there a more
> appropriate plugin I should use? The platform UI is
huge and I'm not at
> all familiar with the big picture.
org.eclipse.ui.workbench can't have a
dependency on org.eclipse.core.resources. We should move it
to org.eclipse.ui.ide.
In org.eclipse.ui.ide, you can create your
Show In System Explorer command and then you need to
contribute it to org.eclipse.ui.menus.MenuUtil.SHOW_IN_MENU_ID
(popup:org.eclipse.ui.menus.showInMenu) The 3 preferences (or one platform preference)
can be added to org.eclipse.ui.internal.ide.dialogs.IDEWorkspacePreferencePage
> 2) I used my Kepler installation as the API baseline
when developing; is
> that the proper thing to do, or should I be using
something more specific?
Because we're early on, I think that's fine.
We'll review the contribution in the context of Luna. You
can get the 4.4 M2 drop of the SDK at http://download.eclipse.org/eclipse/downloads
but that shouldn't make a difference to your patch for now.
> 3) In cases where I had to upgrade plugin versions, I
got some weird
> version numbers (e.g. 3.106); is that because of the E4
stuff? (i.e. the
> 3.x layers in E4 were bumped up to 3.100). And since I
mentioned this,
> should I perhaps only be using stuff in
org.eclipse.e4.ui.[whatever]?
Yes, when we delivered Juno we delivered
ui.workbench 3.8 and 3.103 (because of the parallel
development). Luna will be org.eclipse.ui.workbench 3.105
(the correct API baseline for Luna development is Kepler
4.3)
org.eclipse.e4.ui.* represents the Platform
UI Eclipse4 technology. Renderers, Model, DI, context
hierarchies are all managed from those plugins. For this
functionality, org.eclipse.ui.ide is probably correct.
> 4) There's some OS-specific stuff in there. Currently
I've added a piece
> of code that tries to provide sensible defaults for
three cases (Linux,
> Mac OS X and Windows). The feature works for all cases,
you just don't
> get a default if you're running something else (you are
prompted to
> configure the launcher command in the preferences
instead). A couple of
> things here:
>
> 4.1) Is that "allowed" or must everything support all
officially
> supported platforms? I'd need help from people with
access to other
> platforms in order to get sensible defaults for those.
While I'm open to suggestions on this, I'm
fine with having this work for windows, linux, and mac as
long as the failure case on other platforms is reasonable
and not too intrusive.
> 4.2) Is it required (as in coding guidelines) to have
all
> platform-specific features contributed by
plugins/features targeting
> specific environments, or is it ok to have this set in
a
> non-platform-specific plugin using if statements (like
I did now with
> org.eclipse.ui.workbench). Which plugins should I use
in the latter case?
If we're accessing API that's not available
on all platforms we must use fragments. For example,
org.eclipse.ui.win32 or org.eclipse.e4.ui.workbench.renderers.swt.cocoa
(we don't have a linux specific fragment at the moment).
If the API is the same on all platforms then
it's OK to use org.eclipse.jface.util.Util.isMac()
and similar methods. For now I'd start in ui.workbench and
if we need to break it out we can.
>
> 5) I haven't written any unit tests. Can you point me
towards existing
> unit tests for something similar (e.g. the show in
properties) but which
> is recent code, so I can have a look at an up-to-date
approach (e.g.
> which frameworks for testing and mocking are used,
etc)?
We're still using JUnit. See the org.eclipse.ui.tests.api package for examples of
tests you can use.
Thanks for your interest in this, Alex.
Later,
Paul
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
