Re: [ide-dev] Ctrl-1 driven development

["Eric Moffatt" <emoffatt@xxxxxxxxxx>]

Yeah, McQ and I had discussed this in the past. I wanted a 'Packlid' button for broken editors and views that, when clicked, would install whatever was needed to get the view 'real' again (FYI, Packlids were dumb aliens from Star Trek whose main line was 'Make it go"...;-).

I'm not really sure how much this would impact the need to be connected though. They should only need a connection when they're 'setting up', once they have the right setup (for them) it shouldn't be necessary to be connected.

As far as 'slimmer' packages go I'm all for it but doubt that it'll solve the issue. Taken to its logical conclusion we'd have discreetly installable features for every UI extension...that would of course be insane but if it isn't true then we will need a mechanism to 'cull' extensions that aren't related to what the user wants. Just because they install the 'foo' editor they might not want associated views and other cruft unrelated to the editor.

I'd love to see an implementation of the Plugin Registry view that uses a checkbox tree and allows me to individually pick the extensions I want, that way I could hide *anything* I don't want to see. Of course this just makes the micro-management issues bigger but if such information could be included in an Oomph 'install' then we could do a fair amount of fine-tuning of the UI without altering the current features (although that may well still be a good idea). Note that I don't really care about the size of the jar itself so having 'code' for views / perspectives and commands the user will never see isn't an issue (to me).

Eric

Konstantin Komissarchik ---10/22/2015 02:25:54 PM---If we had on-use installation of components integrated throughout the IDE, then I would be more supp

From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
To: Szymon Ptaszkiewicz <szymon.ptaszkiewicz@xxxxxxxxxx>, Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: 10/22/2015 02:25 PM
Subject: Re: [ide-dev] Ctrl-1 driven development
Sent by: ide-dev-bounces@xxxxxxxxxxx

---

If we had on-use installation of components integrated throughout the IDE, then I would be more supportive of having slimmer packages. Unfortunately, this is a phenomenal undertaking and no one is stepping up to do the work. It’s not even clear to me that this is achievable in general. Sure, there are some obvious trigger points, such as opening a file with a certain extension, but that will not cover everything. Lot of work would be needed to make on-use installing stubs of various Eclipse constructs, such as views, projects, etc.
 
Further, let’s not forget that even the most clever on-use installation can be a pain for users because it relies on effectively constant network access when the IDE is used. This makes it difficult to plan for connectivity gaps, such as being on a plane. Installing Eclipse wouldn’t be enough, you’d have to go around and touch all the areas that you will need while you have connectivity.
 
These are solvable issues, but require a lot of hours that someone has to be willing to contribute.
 
In the meantime, package composition is the only tool we actually have to combat user perception that Eclipse is an incomplete IDE.
 
- Konstantin
 
 

From: Szymon Ptaszkiewicz
Sent: Thursday, October 22, 2015 2:33 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Ctrl-1 driven development
 
 
> As to the rest… If installable components were easy to discover and user didn’t mind doing this, we wouldn’t see comments about Eclipse missing basic functionality, like XML support. 

I don't think we disagree on that one either, maybe just a different point of view. My point is that installing new features is a standard procedure and it should not be something we should try to avoid with more "complete" EPP packages to show our users that what we ship is complete. Instead of avoiding installing, a better approach would be to make it as easy as possible up to the point where it is almost invisible so that the user does not need to bother to think about installing new features that he may need but rather the features are just there at the time he starts using them. Think of it as an equivalent of OSGi's "lazy loading" - "lazy installing" -- it is invisible to the end user, you don't know when it happens and how it is done exactly but it works and let's you get the job done. What Torkild proposed in this thread previously seems like a good way to achieve that. I think that Eclipse does provide a complete solution, we just need to make it act as one rather than as several semi-complete packages.

> When our competition ships a complete product and we ship a box of parts with a “some assembly required” sticker, we don’t position Eclipse in a good light. Rather like in the car world, we have a relatively small community of folks who like to tinker with their IDE, but the majority of people just want to get the job done.

As you mentioned, components are not easy to discover which means this is a problem with discoverability rather than with completeness of what we ship. EPP packages do not address the discoverability issue but the perceived completeness of what Eclipse ships issue and even for that issue it's not the best solution.

Thanks,
Szymon

Konstantin Komissarchik ---2015-10-21 18:10:46---I agree with you on one point… EPP should be installing everything as a top-level feature so that up

From: Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>
To: Szymon Ptaszkiewicz/Poland/Contr/IBM@IBMPL, Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: 2015-10-21 18:10
Subject: RE: [ide-dev] Ctrl-1 driven development

I agree with you on one point… EPP should be installing everything as a top-level feature so that updates work properly. 

As to the rest… If installable components were easy to discover and user didn’t mind doing this, we wouldn’t see comments about Eclipse missing basic functionality, like XML support. 

When our competition ships a complete product and we ship a box of parts with a “some assembly required” sticker, we don’t position Eclipse in a good light. Rather like in the car world, we have a relatively small community of folks who like to tinker with their IDE, but the majority of people just want to get the job done.

Thanks,

- Konstantin



From: Szymon Ptaszkiewicz
Sent: Wednesday, October 21, 2015 4:45 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Ctrl-1 driven development


> because Eclipse.org was pushing the "lowest common denominator"

Well, to me that was a tradeoff.

One significant advantage of using the "lowest common denominator" is that whatever you install on top of it, it is installed as the root feature which means "Check for updates" works as one might expect. And in order to install anything you need to go to Help > Install New Software... and then browse the list to find what you need. You achieve 2 goals: user has to browse the list manually so he gets familiar with what he can find there and "Check for updates" works.

In case of EPP packages, we try to be smart and collect features that certain group of people may need, but as shown in this discussion this is not always easy and there are different opinions whether functionality X should be part of package Y. So we achieve 3 goals: packages don't meet users' needs (or at least are controversial), "Check for updates" does not work and we have endless discussions how to provide better packages and possibly release it more frequently to mitigate the lack of "Check for updates".

The tradeoff is that we replaced flexibility of a thin base package (be it Eclipse SDK or a thin EPP package) with predefined suitability of EPP packages which is not always really suitable. In order to explain the difference to a regular user, you need to explain what root features are there and this is an advanced topic even for professionals and experienced Eclipse users. To me, it is better to give a thin base and then let the user choose what he needs to install while at the same time he learns what other cool features are there, rather than give them what we think he may want and either way expect him to find and install additional stuff. Explaining how to install a new feature is a basic discussion and can be done with any user even newcomer, but explaining why some features benefit from "Check for updates" and some not is a lot more difficult.

To summarize, I'm not sure if we are "recovering" in the right direction.

Szymon

"Max Rydahl Andersen" ---2015-10-21 12:35:43---On 20 Oct 2015, at 18:57, Wayne Beaton wrote: > FWIW, I regard the Eclipse SDK as the output of the

From: "Max Rydahl Andersen" <manderse@xxxxxxxxxx>
To: "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
Date: 2015-10-21 12:35
Subject: Re: [ide-dev] Ctrl-1 driven development
Sent by: ide-dev-bounces@xxxxxxxxxxx

On 20 Oct 2015, at 18:57, Wayne Beaton wrote:

> FWIW, I regard the Eclipse SDK as the output of the Eclipse project, 
> not one of our front-line "consumer" downloads. 

exactly and it is only recently (last year?) we finally got the download 
page to not serve the "basic" package as default.

I think alot of users missed things like code recommenders, maven and 
xml for years purely because Eclipse.org was pushing
the "lowest common denominator".

It will take some time to 'recover' from this.

/max
http://about.me/maxandersen
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev


 
 _______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev