[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Furthering the (Early) Adoption of Eclipse 4
|
In a similar vein, we (the deeplinking team) want to start putting documentation somewhere. We currently have our documentation in docbook format. I've sanitized and extracted it to an XML file.
It would be awfully nice to have proper HTML / PDF documentation, and as far as I'm concerned I don't care if it starts as a set of Wiki pages or as a Docbook XML document.
Before I put a bunch of effort into converting our docs, I was hoping to get some insight into what others are thinking along these lines.
Regards,
Dave Orme
PS: Thanks to the E4 team for moving forward with moving our repo to Git. That will be a big help. :)
On Tue, Sep 21, 2010 at 2:58 PM, Eric Moffatt
<emoffatt@xxxxxxxxxx> wrote:
Stefan, Thanks for the feedback and
most especially for the 'doc' plugin framework !!
I've updated the wiki (http://wiki.eclipse.org/E4/40Review)
and added 'Documentation' and 'Tooling' sections already as well as capturing
your input.
Eric
Hi e4 team,
in response to Mike Wilson's message, this mail is about what I think needs
to be done to further the (early) adoption of Eclipse 4. I am writing this
as an RCP developer and a plug-in developer since the days of Eclipse 2.0.
Here's my wish list for the next milestone:
1. SOURCE PLUGINS. Include the source plugins for e4 and
EMF
in the builds. I fully agree with Tom that this is
a must-have.
(Installing the source via P2 doesn't work for me.)
See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=320768
2. DOCUMENTATION. Don't get me wrong. I am not asking for
extensive
and complete documentation at this time. But, I just
think that
a bunch of wiki pages with mostly internal discussions
and to-dos
is not sufficient. Wiki pages lack structure. They
don't give
you an idea of "what's in", and so you
have to find out yourself;
this costs way too much time. Currently, the available
information is
scattered all over the Web (blogs, tutorials, presentations,
...).
I think there should be a few short sentence about
every important
topic (e.g. model modification, selection listeners),
and a few lines
of example code. This should be possible to produce
within one or
two days of work.
To show you that I am serious about this point, I
have compiled a
documentation plugin that could be as a starting-point
or as a source
for inspiration (unfortunately, its mostly an outline
so far).
See attached screenshot for the outline (table of
contents).
I have filed a bug and attached the plugin source
there:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=325654
3. ADOPTER'S GUIDE. To make it easy for people to begin adoption,
there needs to be some guide explaining what needs
to be changed
(or NOT) to adopt Eclipse 4.
Some important questions to be answered:
- Which APIs will be deprecated? Which are considered
old-style?
- Which APIs are not supported by the compatibility
platform?
- Is the compatibility platform meant for RCP applications?
(Why is there a "LegacyIDE.e4xmi"
file instead of "LegacyWorkbench.e4xmi"?)
- Do RCP applications need to implement their own
workbench
if they want to be "native" Eclipse
4 applications?
- If yes, do they have to implement all the nice
features themselves
they previously got for free (like DnD of
parts and trims, ...)?
- How much adoption is necessary? Just make things
work on the
compatibility layer, or remove all references
to old-style APIs?
4. TOOLING. I am wondering why Tom's tooling hasn't been
included
in the 4.0 release. Well, it might still be in incubation
stage,
but to me it doesn't look less mature than e4 itself.
Just imagine
the 3.x SDK would ship without PDE.
How are people supposed to create their e4xmi files?
Has the LegacyIDE.e4xmi file been created using the
EMF editor?
See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325656
Please note that so far I have not asked for a single feature XYZ. Adding
more features is just a matter of time. What is more important at this
time is, IMHO, that you communicate clearly what needs to be done to adopt
Eclipse 4. (See especially my proposal of the "Quick Comparison"
in the attached Adopter's Guide.)
Now I want to continue my list with some more technical concerns:
5. FIX SWT. If you really want to attract people and enable
them
to style their own applications, make sure that a
number of
bugs in SWT get fixed.
There's a capable man out there, Emil Crumhorn, who
knows how to
make styling easy. He wrote the Ribbon example.
In his blog post at
http://hexapixel.com/2010/01/06/xaml-in-swt-and-where-the-ribbon-is,
however, he states that he cannot continue to refactor
his code
into something easier, because of a number of bugs
in SWT.
Even Eclipse 4.0 is affected by one of the bugs (see
attached
screenshot), and I also have run into this bug using
Draw2D/GEF.
I think this should be done ASAP. Too much time has
already passed.
Known bugs to be fixed:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=181676
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=297467
6. STARTUP PERFORMANCE. As an RCP developer, I strongly agree
with
Doug Schaefer (see http://cdtdoug.blogspot.com/2010/02/ok-eclipse-you-have-3-seconds.html)
that start up performance is important. Eclipse 4
RCP should
not be slower than Eclipse 3 RCP. Unless this is
the case, I would
think twice before porting my app to Eclipse 4.
(I hope to find the time to do some profiling work
on this,
especially for cold starts.)
See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325655
7. TOOL ITEM RENDERER. Just try the following:
1. Open an untitled text file
2. Switch between the Package Exlorer and
the text editor
3. Observe the delay of how the tool items
get updated
(500 ms are way too much)
Now imagine that a whole toolbar (e.g. in a GEF/GMF
application)
gets enabled/disabled. The delay will be much more
noticable (whole toolbar flashing with that delay),
and this will make the UI *feel* sluggish.
I know that the tool item updater has been done for
reasons
of laziness. However, I think that using the "tracked
access" feature
of the contexts, it should be possible to get rid
of this.
Or, the periodic item updater could be replaced with
a non-periodic one once the tool item has been enabled
for the first time.
See bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325657
Best regards,
Stefan Mücke
[attachment "e4-doc-toc.png" deleted by Eric Moffatt/Ottawa/IBM]
[attachment "pixels-out-of-place.png" deleted by Eric Moffatt/Ottawa/IBM]
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev