[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [platform-ui-dev] RE: [jdt-ui-dev] Hyperlinked code feature in M3
|
In the meantime I did some progress in determining, where the prebuild
Eclipse API javadocs may reside and how to possibly set them up for access.
I detected the following two places in the Eclipse M3 plugins directory for
API javadocs:
1. org.eclipse.platform.doc.isv_2.1.0/doc.zip
Inside the doc.zip archive there is a "reference\api" folder
which contains javadocs.
2. org.eclipse.jdt.doc.isv_2.1.0/doc.zip
Inside the doc.zip archive there is a "reference\api" folder
which doesn't contain any javadocs?
The IMO bad thing here is AFAI can see, that for every new java/plugin
project, I would have now always again and again to setup the javadoc
locations for the individual needed own Eclipse jars under the jars
preference page. This looks like a boring repetitive task for different
projects. Or did I missed some point/feature setup here?
Wouldn't it make more sense, if Eclipse would at least have some knowledge
about predefined javadoc locations for it's own accompanied and needed API
libraries? This way a Shift-F2 would be able to present Eclipse's own API
javadocs right out of the box in it's help system. Does something here
prevent (speak against) such a more user friendly approach?
-Valentino
> -----Ursprungliche Nachricht-----
> Von: jdt-ui-dev-admin@xxxxxxxxxxx
> [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]Im Auftrag von Valentino Kyriakides
> Gesendet: Sonntag, 24. November 2002 17:08
> An: jdt-ui-dev@xxxxxxxxxxx
> Betreff: AW: AW: [platform-ui-dev] RE: [jdt-ui-dev] Hyperlinked code
> feature in M3
>
>
> Yes, in order to prevent misunderstandings, since I may have not expressed
> very well what I meant (sorry, english is not my native language), I will
> try to describe it better with some examples. - Note however, that Eclipse
> is really new to me and thus it might be that I'am wrong with the
> following
> points and that there is some to me actually unknown way, to
> yield the same
> wanted overview results. In that case I hope that you can bring in some
> light into the dark.
>
> Lets start...
>
> From inside of a Java Editor I can hover with the mouse over a
> Java element
> which will pop up a sort of main javadoc comment for the element.
> E.g. for a
> class element reference I will get the initial javadoc comment for that
> class. Pressing instead F2 on a selected element gives the
> portion/fraction
> of javadoc comment related to the individual selection (right?).
> Now how do
> I get the full javadoc description for a selected
> class/interface, including
> all the field and method overview comment, as a scrollable pop up?
>
> I thought alright maybe I have to use Shift-F2 here, but this
> shows me that
> the Eclipse API javadocs have not been setup automatically in
> such a direct
> usable form, which BTW would be nice to have as a default.
>
> Let's say I just started to discover SWT and want to try out some of it's
> capibilities, in order to get a better understanding for it's concepts. I
> try some example code and see there two used constructors for GridData:
>
> - GridData()
> - GridData(nnn)
>
> pressing F2 an any of those doesn't give me any descriptive
> javadoc. Further
> GridData(int style) seems to can get some sort of integer styles as
> arguments, pressing F2 on any of those arguments doesn't give one any
> descriptive javadoc comment for possibly available styles. So how does one
> get context sensitive help about what these styles are and what they might
> stand for at all?
>
> That's what I basically meant with "inconsistencies". Even the above
> sketched example is one I just adhoc remember, I found a lot of
> such places
> across the Eclipse API. There are some more places where you won't get any
> direct javadoc context help for selected topics at all.
>
> This somehow looks for me like the degree of javadoc comments (as general
> API documentations) is not overall equally balanced. I believe, that this
> might be (?) in fact related to the general problems of bigger distributed
> development team, where not all team members are writing the same
> degree of
> javadocs for the parts they are working on or might be resposible for. -
> Well this is of course just a speculation from my side, since I don't know
> how this is actually handled by the whole Eclipse development team. Please
> correct me if I'am totally wrong here with this assumption.
>
> As a possibly better describing example I would like to raise the
> following
> scenario. Lets say you use Eclipse and JBuilder side by side, even both of
> these have different underlayed architecture/API concepts. When
> you get lost
> in/by using some JBuilder API functionality, it's context sensitive help
> system offers a better direct overall javadoc overview for the
> selected Java
> element. There you will also get the whole help context surrounding the
> selected element and also direct links (jump marks) to the
> directly involved
> other element topics etc. In contrast here, inside Eclipse I
> always have to
> spend much time, in order to find first some valuable point,
> where the whole
> needed topic surrounding documentation and things related to that may
> reside.
>
>
>
> Greetings Valentino
>
>
>
>
> > -----Ursprungliche Nachricht-----
> > Von: jdt-ui-dev-admin@xxxxxxxxxxx
> > [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]Im Auftrag von Erich Gamma
> > Gesendet: Samstag, 23. November 2002 13:06
> > An: jdt-ui-dev@xxxxxxxxxxx
> > Betreff: Re: AW: [platform-ui-dev] RE: [jdt-ui-dev] Hyperlinked code
> > feature in M3
> >
> >
> >
> > >That results to somehow inconsistent looking javadocs format styles,
> > >especially if you compare JDK docs with those of Eclipse and use both
> > >together. - I dislike this mismatch much.
> > Can you please provide some examples of the inconsistencies you see?
> > --erich
> >
> >
> >
> >
> >
> > "Valentino
> >
> > Kyriakides" To:
> > <jdt-ui-dev@xxxxxxxxxxx>
> > <vkyriakides@web. cc:
> >
> > de> Subject: AW:
> > [platform-ui-dev] RE: [jdt-ui-dev] Hyperlinked code feature in
> > Sent by: M3
> >
> > jdt-ui-dev-admin@
> >
> > eclipse.org
> >
> >
> >
> >
> >
> > 11/23/2002 01:00
> >
> > AM
> >
> > Please respond to
> >
> > jdt-ui-dev
> >
> >
> >
> >
> >
> >
> > I know and F2 works now better under M3 I've just installed, as for the
> > previous versions I've tried out.
> >
> > However, some API classes are still poorly documented and the javadoc
> > documentation style used for most Eclipse API classes etc. is far
> > away from
> > what the guidelines mentioned under:
> http://dev.eclipse.org/javadoc.html.
> > That results to somehow inconsistent looking javadocs format styles,
> > especially if you compare JDK docs with those of Eclipse and use both
> > together. - I dislike this mismatch much.
> >
> >
> > -Valentino
> >
> >
> > That makes me wonder
> > > -----Ursprungliche Nachricht-----
> > > Von: jdt-ui-dev-admin@xxxxxxxxxxx
> > > [mailto:jdt-ui-dev-admin@xxxxxxxxxxx]Im Auftrag von Scott Stanchfield
> > > Gesendet: Freitag, 22. November 2002 15:54
> > > An: jdt-ui-dev@xxxxxxxxxxx
> > > Betreff: RE: [platform-ui-dev] RE: [jdt-ui-dev] Hyperlinked
> code feature
> > > in M3
> > >
> > >
> > > > 3. The hover javadoc popups inside the java editor only show a
> > > > short broken
> > > > fraction of the whole javadoc. The information shown there often
> > doesn't
> > > > show enough of the javadoc explanation for the selected
> > > elements. Further
> > > > this popup actually isn't scrollable, so that it possibly could
> > > > show more of
> > > > the javadoc contents related to an selected element, if it would be
> > > > scollable (?).
> > >
> > > You can press F2 to get the full javadoc as a "tooltip", with
> > > scrollbars...
> > > -- Scott
> > > _______________________________________________
> > > jdt-ui-dev mailing list
> > > jdt-ui-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
> > >
> >
> > _______________________________________________
> > jdt-ui-dev mailing list
> > jdt-ui-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
> >
> >
> >
> > _______________________________________________
> > jdt-ui-dev mailing list
> > jdt-ui-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
> >
>
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
>
