Currently this flag is only used to select the templates. I would dislike having plug-in dependencies automatically added. Maybe you can better provide a JFace and SWT template in the template section if that flag is set?

Currently this flag is only used to select the templates.

It marks this plugin as a singelton also

I would dislike having plug-in dependencies automatically added.

Why?

Maybe you can better provide a JFace and SWT template in the template section if that flag is set?

It seems odd to require an additional step, beside that what should such "template" offer?

Why

Because I may want to make a menu contribution via model elements and in this case I do not need SWT and JFace.

Why

Because I may want to make a menu contribution via model elements and in this case I do not need SWT and JFace.

That's what I mean with "and easy to remove in rare cases where it is not desired", having only a menu contribution without defining any handler that do not reference anything (e.g. shells, dialogs, ...) is likely seldom. And even in that case there is a high chance one later adds new features to the plugin that still require SWT/JFace.

Its is also easy to add dependencies, if you need it.

-1 from me for such adjustments.

Its is also easy to add dependencies, if you need it.

No one questions it, but if I have two "easy" options and I need Option 1 in 99% of the time and Option 2 in 1% of cases it is clear what should be the obvious default... currently it is the reverse...

You could add a template for your 99% use case.

@laeubi if you want this, please ask a PDE project lead to resolve our conflict.

You could add a template for your 99% use case.

Using a template is simply over engineered here and more complex, first it needs another step, then I need to find it (not to mention that I need to know about this).

Also it is simply bad UX if I need to take action for the most common usecase ... from my point of view real problem of Eclipse IDE is not darkmode, startup times or fancy new feature, the main problem is that we make it extremely hard for users to perform their (common) task because we hide everything behind options multi-page wizards and insider knowledge ...

Its is also easy to add dependencies, if you need it.

No one questions it, but if I have two "easy" options and I need Option 1 in 99% of the time and Option 2 in 1% of cases it is clear what should be the obvious default... currently it is the reverse...

Although I'm not sure if the numbers are that clear (in fact I can only guess from my own experience), I also assume that in the majority of cases where that option is enabled one also uses SWT/Jface.

Currently this flag is only used to select the templates. I would dislike having plug-in dependencies automatically added. Maybe you can better provide a JFace and SWT template in the template section if that flag is set?

If that option is without effect if no template is selected, would it then be a solution to only add these dependencies if no template is selected later? If one doesn't want those dependencies then one should simply not check this box. The existing templates are then not changed.

IIRC that option also has an effect if an activator is generated, which then extends UIPlugin instead of Plugin? I have to check it when I get back home. But wouldn't that be acceptable?

Strange behaviour, I saw my comment twice now both are gone....

To repeat: if @HannesWell is fine with the proposal to add SWT and jface if the UI flag is set that is fine for me.

Strange behaviour, I saw my comment twice now both are gone....

I got one mail for the previous comment (which is also gone for me) and this one.

To repeat: if @HannesWell is fine with the proposal to add SWT and jface if the UI flag is set that is fine for me.

Great. Assuming everything is as I described in my last post, I don't see a real drawback.

The 'Make contribution to UI' choice does the following things :

• add the dependency to org.eclipse.ui (which depends on jface and swt)
• make the(optional) activator extend AbstractUIActivator instead of implementing BundleActivator
• change the template choices in the next page
• create extension(s) depending on the (optional) selected template and if there are extensions the plugin is set as a singleton

That was the default behavior for Eclipse 3 ui Plugins. With Eclipse 4 we have different behaviors. We can :

• create an hybrid E3/E4 UI plugin with both extensions and model fragments in this case it uses swt/jface and depends on org.eclipse.ui
• create a pure E4 UI plugin using swt/jface : In this case only a dependency to swt/jface should be provided (no dependency to eclipse.ui)
• create a pure E4 UI Plugin using javafx, if efxclipse is installed (rare case but technically possible (in 10 years I had only 1 customer who has done that)...
• in theory, if another renderer exists, we could imagine to have other graphical libraries (but no other renderer exists as far as I know)...

If we give the choice between E3, E3-E4, E4, we will show that different UI concerns can be managed, and we will be able to filter the the templates choice in the next page (even for the templates proposed if we choose 'create a RCP application')...

So this current issue is may be to specific and should be considered in a more general way, this is why I opened the issue #1378 (that was already opened on the bugzilla in 2018 but automatically closed yesterday...)...

By the way in the previous Wizard ask what OSGi framework is to be used, maybe instead of "make contributon to the ui" would be having a drowdown with options:

• No UI Framework
• E4
• E3
• E4 with compatibility layer

Hello team,

I’m currently working on setting up the development environment for this project and could use some assistance. I’d like to schedule a time to connect with a maintainer or contributor who could guide me through the initial setup process. Screen sharing would be ideal to ensure I’m correctly configuring everything.

Thank you in advance for your help and time. I look forward to working together to get this set up!

Best regards,
Abdul

Hi all, I'm from a team of four people working on our first OSS contributions. This will be our first ticket on Eclipse and we are nearing a solution. Currently, we are able to add the dependencies automatically by modifying pde.internal..ui.wizards.plugin.NewProjectCreationOperation.java | getDependencies() - though we know our code is almost certainly in the wrong place. We will submit a PR soon (that we expect to be rejected) to solicit feedback on our code's formatting and our next steps.

Additionally, we plan on addressing the concerns of @vogella by including a second automatically selected checkbox in the plugin wizard titled "Include SWT and JFace as dependencies" that appears when "This plug-in will make contributions to the UI" is checked. No promises, but we may also check out issue #1378

@HannesWell we would appreciate your feedback once we submit our PR, if possible.

I’m currently working on setting up the development environment for this project and could use some assistance. I’d like to schedule a time to connect with a maintainer or contributor who could guide me through the initial setup process. Screen sharing would be ideal to ensure I’m correctly configuring everything.

Hello @Rauoof814 are you working together with @ejDeister as part of the Code Day program?

Did you already had a look at https://github.com/eclipse-ide/ ? This page should provide all the information to guide you through the contribution process. If that isn't sufficient, please let us know.

Hi all, I'm from a team of four people working on our first OSS contributions. This will be our first ticket on Eclipse and we are nearing a solution. Currently, we are able to add the dependencies automatically by modifying pde.internal..ui.wizards.plugin.NewProjectCreationOperation.java | getDependencies() - though we know our code is almost certainly in the wrong place. We will submit a PR soon (that we expect to be rejected) to solicit feedback on our code's formatting and our next steps.

Great :) I'll have a look at your PR tomorrow. And don't worry, we will work through it and you can then update the PR until it's in good shape.