Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] UX Discussion - New Project Wizard

I think _javascript_ is the way to go. At the end, something like freemarker ‎or embedded _javascript_ would fit the problem well.

My problem with Xtext and friends is that they're prett‎y heavy weight for this problem. And they still require creating plug-ins to hold the generated code.

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: kesselhaus
Sent: Saturday, May 17, 2014 6:35 PM
To: cdt-dev@xxxxxxxxxxx
Reply To: CDT General developers list.
Subject: Re: [cdt-dev] UX Discussion - New Project Wizard

Not sure if it fits here, but I guess you remember that there was once the Rhino project to have scripting support in Eclipse.
The project dies some years ago, but it seems, someone want to revive it as EASE

https://projects.eclipse.org/proposals/eclipse-advanced-scripting-environment-ease

Something on Eclipse, that I found always too bad was, that a Non-Java Developer could never really extend Eclipse.
>From my side, the entry curve to extending Eclipse was to high, as you would have to learn Java, Eclipse, PDE and whatever first.

I'm also not sure, if EMF, Xtext, Xtend, Xpand, EMF Forms would be of any help here?
Sure, that's more dependencies to CDT, but if it's useful, why not?

Regards,
kessel


Am 23.04.2014 21:42, schrieb Doug Schaefer:
Excellent, gang, this is all great input. As I expected we're all kind of coming at this from different angles and it's quite a challenge to satisfy them all. But we should give it a good try.

I like Elena's point that in the end, this is really all about the template. What does the project look like after we're done. The wizard is about tweaking the values and behavior of the template generator. The differences between the templates really shows we need to be a bit more generic about that.

As an example, for Qt, you select an instance of qmake you want to use to generate the makefiles. That instance implies a toolchain, so why even present the toolchains pain? When you want to add toolchains, you create new build configurations and set the qmake you call for that config and generate to a new build output directory. (BTW, this is what's driven me here, trying to figure out how to do this properly).

Now, if you sum up all the potential templates, still end up with a problem of scale. We need to figure a way to categorize them. That'll be the tricky point and will need some more thought.

And speaking of the template generator, as much as I love the Symbian guys who contributed it, I find it a pretty complicated. I'd love to find a way to be able to add templates without writing Java code, especially now that we're on Java 7 and have access to _javascript_. That could be another activity we kick off from this.

But I definitely agree with the sentiment that we need to consider all the use cases. You've presented a few so far. I'd love to hear more examples.

Thanks!
Doug.



From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Alena Laskavaia [elaskavaia.cdt@xxxxxxxxx]
Sent: Wednesday, April 23, 2014 1:58 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] UX Discussion - New Project Wizard

Personally I think the selection matrix is too huge, so instead of trying to classify everything, we can just have some
flexible way of extending wizard so each vendor will use what is applicable for them. Generically speaking everything is
a template, so user can pick one of the project templates (in most generic sense) then move to the next page of the wizard where
he can pick more specialized templates of this type, and so on. For out of the box cdt/toolchain (such as wascana) first level choices can be "New Application", "New Library", "Existing Source", then second level for library would be something like "Static", "Shared", "Custom Makefile" etc.
But if we add tools for mobile development, first level for example can become "Desktop" and "Mobile".
Most of the other choices have to be deducted from template, for example when creating project from existing source user have
to choose project location outside of workspace, but when user creates "Desktop Application" -> "Hello World C++" we assume it is managed AND it is located in workspace, so we won't ask anything else. Of cause there will be some "I will configure everything myself" template for whatever we did not consider.



On Tue, Apr 22, 2014 at 3:16 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
Hey gang,

Even though we're a community spread across the globe, it's important that we have real design discussions and help plan out our future directions. We can start here on the mailing list, and as part of this discussion, we can move it to a different venue if it becomes too noisy or too awkward to make our points. As you can tell from my blog, http://cdtdoug.ca, I love to write, so this works best for me, but I moved to QNX to work with a team that sits within spitting distance of each other because I love that interaction too, well, except for the spitting.

I'd like to do something with the New Project wizard. I've wanted to do that for a long time. And now that we've gone through the exercise in Momentics, I think we can bring some of that experience to the CDT and the Eclipse C/C++ IDE in particular, and anyone else who wants to contribute ideas and/or code to reuse it themselves. But I'm not sure I have the full perspective on everything all CDT projects would need.

First up, the biggest problem is the first page, and the Project Type and Toolchains panes in particular. What is a project type. Is it the type of binary output, executable or library? Is it the build system, autotools or qmake or cmake? Is it the kind of application, command-line or GUI or plug-in. The target platform, BlackBerry or Desktop or Server?

Or do you pick the toolchain you want first and then the project type? The UI was mainly designed by a contributing company that offered an alternative compiler to gcc so the choice was left second which made sense in those scenarios. But how does GCC cross fit into that. For many of us, toolchain implies target platform, but wouldn't you select the target platform before picking the project type and then selecting a toolchain? Are we missing something there?

Right now we have quite a mix of concepts being presented in these two panes, project type and toolchain and the cohesion is terrible. I'd love to hear what you all think of the dialog and how you think it should be changed to make more sense to our users.

Thanks!
Doug.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev




_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top