[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cross-project-issues-dev] Europa impressions
|
> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-
> project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
...
> I have now installed everything from Europa RC1 and would like to
> comment
> on my impressions.
Thanks for the clear summary and pointers Pascal. Regarding the Mylar parts
of this, the high-level comment is that Mylar pushes on Eclipse's
extensibility very hard because of how primary a part of the user experience
we have made tasks (basically parallel to files). That said we try really
hard to make our UI additions elegant and relevant.
1) Dialog on first start: this will be gone in next week's build and we are
now relying on new Welcome content being displayed. Fyi the bug is:
187880: [new eux] Don't open a dialog when Mylar starts for the first time
https://bugs.eclipse.org/bugs/show_bug.cgi?id=187880
2) Eager loading on startup: for at least Europa both those plug-ins will
need to start Eagerly if Mylar is being used. Mylar's point of view is that
the Task List is as important to the workspace as the projects that are
checked out, so it has to load on startup. For example, if the user had an
active task, it has to be re-activate on startup (or we're breaking the
guideline of restoring workbench state on startup). The Mylar Team plug-ins
startup to initiate the change set management, because Platform/Team does
not provide us with a mechanism for persisting our custom change sets so we
have to re-create them on startup if used. So as far as I can tell we are
stuck with both startup extensions for now, although I really would like to
get it down to one. If anyone has specific comments or concerns about this
on this please reply consider commenting on:
173150: manage Mylar participation in Europa
https://bugs.eclipse.org/bugs/show_bug.cgi?id=173150
3) Perspective extensions. We are careful about our perspective extension
and action set visibility, but there is no point installing Mylar if you do
not want to use its Task List instead of the Tasks support in the Tasks
view:
176986: [Markers] Move tasks into the problems view
https://bugs.eclipse.org/bugs/show_bug.cgi?id=176986
So we placed the Task List beside the Tasks view to encourage the user to
pick one. The result is very bad in Pascal's screenshot, where everything
is squashed by Welcome. What I have just done to address this is to move
the Task List to be stacked under the Outline. I plan on keeping the other
perspective extensions as is for the Java and Resources perspectives, so
please comment if you have any other concerns.
4) The <workspace>/.mylar directory. I dislike the fact that we do this,
but it is the most elegant solution that we could come up with. To the
Mylar user tasks are as important as files and we do not consider them to be
workspace-specific settings that can go into .metadata. For example, some
users share the same .mylar folder across different workspaces (by moving it
out of the workspace folder and setting a preference. I have been
considering ways that we could hack that location into .metadata but that
could cause more harm than good. If anyone has complaints or suggestions on
how better to do this please post on the following bug which has some of the
background discussion, or file a new bug for this if writing to the
workspace root considered a blocker for Europa.
130658: improve support for multiple workspaces
https://bugs.eclipse.org/bugs/show_bug.cgi?id=130658
Mik
> First startup
> -------------
> On the first startup, the user experience ended being a nightmare. I
> selected a topic in the Welcome screen and it took well over 25 seconds
> before the Eclipse Help window appeared, and during this time the UI
> was
> not refreshed and it appeared that Eclipse had frozen.
>
> It turns out the root of this problem is caused by having too many
> plug-ins
> contributing to the UI early startup extension point so they are
> started
> automatically when Eclipse starts. Is it necessary for all of these
> plug-ins to be started on every startup? I encourage the plug-in owners
> for
> these plug-ins to review why they using this extension point, and
> perhaps
> defer their plug-in initialization until later. (see list in attached
> screenshot)
>
> Also when I started Eclipse, I was presented with a Mylar dialog
> welcoming
> me to the Mylar project. This was unexpected and perhaps should be
> integrated into the Intro page.
>
>
> Cluttered UI
> ------------
>
> Now added to the Resource perspective (originally contributed by the
> Platform), are a second task list and two IP-XACT views. This is just
> one
> example but it seems like many people are contributing their views to
> other
> people's perspectives. People must be careful when doing this because
> 1) it
> can end up in places without context and 2) if everyone contributes to
> the
> same perspective, it can get very cluttered. The same also applies to
> menu
> items, toolbar buttons, etc.
>
> There is a new view called the Task List view contributed by Mylar
> which
> can cause confusion with the Tasks view contributed by the Platform.
> (note
> it appears in multiple perspectives)
>
>
> Unwanted project
> ----------------
>
> When I first opened the Resource Perspective, there was already a
> project
> named "JSR-109 Web Services" in my Project Explorer. The first problem
> is
> that I didn't create this...who did? And why? The second problem is
> that
> the project is unresponsive to standard actions and I am unable to get
> a
> context menu on the resource. Therefore I can't delete it, etc. So I
> thought that I would find the project location and delete it from disk
> but
> it was not created in the default workspace location. And I cannot find
> the
> location because the resource properties are unavailable.
>
>
> Writing to bad locations
> ------------------------
>
> Upon investigation of the file-system, I discovered that there were
> multiple files written to the Eclipse install location, which must be
> treated as a read-only location. These files should really be written
> into
> either the workspace metadata directory or the configuration area.
> (derby.log, corona*.log, JackRabbitRepositories)
>
> When looking into the workspace directory itself, I see directories
> created
> there that do not have any corresponding projects in my workspace. As a
> rule, the workspace directory is owned by the Resource plug-in and it
> should be treated as a private area. However, you are able to write
> into
> the .metadata directory and this is probably where these files/folders
> should be moved. (.mylar, Eclipse Monkey Examples, Datagraphs, etc)
>
> Upon further inspection, I opened the Navigator view and found some of
> those folders/projects. So 1) why are they not present in the Project
> EXplorer? 2) why are these projects created for free?
>
>
> Summary
> -------
>
> I have opened bugs for some of these issues and I encourage others to
> download and test Europa and do the same. Its only with real
> integration
> testing and use of the product as a whole that we will sort out some of
> these issues and get to a point where it looks like Europa is not just
> a
> bunch of projects thrown together at the last minute.
>
> So here are a few rules to remember, most of which requesting action
> from
> your part. I know it is late but if it is not done now, it will never
> be.
> - Your plug-in is not the most important thing:
> - do not start your plug-in on startup.
> - do not gratuitously put your views in random perspectives
> - do not contribute menus / action sets to all perspectives
> - do not create projects in the workspace on startup.
>
> - Not all folders can be written into
> - do not write into the eclipse install location. In many cases
> this
> will be marked read only.
> - do not write at the root of the workspace. Write in the
> .metadata
> folder instead.
>
> - Performance and UI responsiveness
> - http://wiki.eclipse.org/index.php/Performance_Bloopers
> - make sure to run long running operations in the background
> using
> the jobs API
> - use as much as possible Job API instead of creating threads
>
>
> I'm sure I have forgotten things here, this is far from an exhaustive
> list.
> But what I'm getting at is that first impressions mean a lot and we
> want
> users to have a good out-of-the-box experience with Eclipse.
>
> Now you are likely asking "who are you to talk to us like that?". I'm a
> developer who takes pride and care in crafting something that works,
> performs and does not look too goofy, and I want to be proud, not
> ashamed,
> by the Europa content.
>
> Thanks for your attention,
>
> PaScaL
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
