Planning for 4.8

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Planning for 4.8

Lars Vogel-2
Friends of Platform UI,

I started a planning wiki for 4.8.
If you plan to work on a "bigger" item, please contribute it here.

https://wiki.eclipse.org/Platform_UI/Plan/4.8

In addition to the "normal" items like performance, code cleanup and
UI simplifications, I  added the "Tip of the Day" point. AFAIK Sopot
plans to work on this.

I also would love to see that he introduce null annotations in our
code base. Is anyone interested in working on this one?

Best regards, Lars

--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [hidden email], Web: http://www.vogella.com
_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Mickael Istria-5
Hi Lars,

I'd like to add a few items, not sure how to label and group them right now:
* Enrich the generic editor: Add to the Generic Editor missing interesting features such as folding, aggregated hovers... (several bugs https://bugs.eclipse.org/bugs/buglist.cgi?classification=Eclipse&component=Text&list_id=16305519&product=Platform&query_format=advanced&resolution=---&short_desc=generic&short_desc_type=allwordssubstr )
* Factorize common code features, commands and actions into a Language Toolkit: The idea is to have Platform UI/Text providing the definition of the very usual code-related commands, so each language could simply add handlers rather than redefining commands. That would also allow a better factorization of UI and shortcuts, and thus more consistency across plugins.
* Provide "state of art" classes for Platform adopters: Currently, many classes have a lot of I<MyFeature>Extension<N> which provide additional value which is usually considered as "state of art" in modern IDEs. It's not easy for adopters to figure out the value provided by those extensions and to think about implementing them, and even to implement them. We should consider providing some "state of art" classes that take advantage of all extensions and  implements good default to minimize adoption. An important point is that we should design and document those classes as easily moveable, to easily allow us to add support for another extension without surprising users.

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Mickael Istria-5
Another item would be:
* Integrate Eclipse Platform into user workflows: User workflows are not necessarily mapping Eclipse Platform's one. As example, if we consider file edition, many users like to just open a file and don't think about the concept of "project" whereas Eclipse Platform requires "projects". In this idea, the Eclipse Platform should try to integrate itself into user workflows as they're used to with other tools, rather than ignoring those workflows and forcing users to adopt Eclipse's specific ones only.

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Daniel Megert
> As example, if we consider file edition, many users like to just open a file and don't think about the concept of "project" whereas Eclipse Platform requires "projects".

I assume that you know there's File > Open File... Just wanted to mention it here for others.

Dani



From:        Mickael Istria <[hidden email]>
To:        "Eclipse Platform UI component developers list." <[hidden email]>
Date:        17.05.2017 09:17
Subject:        Re: [platform-ui-dev] Planning for 4.8
Sent by:        [hidden email]




Another item would be:
* Integrate Eclipse Platform into user workflows: User workflows are not necessarily mapping Eclipse Platform's one. As example, if we consider file edition, many users like to just open a file and don't think about the concept of "project" whereas Eclipse Platform requires "projects". In this idea, the Eclipse Platform should try to integrate itself into user workflows as they're used to with other tools, rather than ignoring those workflows and forcing users to adopt Eclipse's specific ones only._______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Lars Vogel-2
In reply to this post by Mickael Istria-5
Hi Mikael,

Please add them to the wiki in case you or your team plan to work on it. Only the following is IMHO already covered by the "improve our API point": Provide "state of art" classes for Platform adopters 

Am 17.05.2017 9:14 vorm. schrieb "Mickael Istria" <[hidden email]>:
Hi Lars,

I'd like to add a few items, not sure how to label and group them right now:
* Enrich the generic editor: Add to the Generic Editor missing interesting features such as folding, aggregated hovers... (several bugs https://bugs.eclipse.org/bugs/buglist.cgi?classification=Eclipse&component=Text&list_id=16305519&product=Platform&query_format=advanced&resolution=---&short_desc=generic&short_desc_type=allwordssubstr )
* Factorize common code features, commands and actions into a Language Toolkit: The idea is to have Platform UI/Text providing the definition of the very usual code-related commands, so each language could simply add handlers rather than redefining commands. That would also allow a better factorization of UI and shortcuts, and thus more consistency across plugins.
* Provide "state of art" classes for Platform adopters: Currently, many classes have a lot of I<MyFeature>Extension<N> which provide additional value which is usually considered as "state of art" in modern IDEs. It's not easy for adopters to figure out the value provided by those extensions and to think about implementing them, and even to implement them. We should consider providing some "state of art" classes that take advantage of all extensions and  implements good default to minimize adoption. An important point is that we should design and document those classes as easily moveable, to easily allow us to add support for another extension without surprising users.

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Lars Vogel-2
In reply to this post by Mickael Istria-5


Am 17.05.2017 9:16 vorm. schrieb "Mickael Istria" <[hidden email]>:
Another item would be:
* Integrate Eclipse Platform into user workflows: User workflows are not necessarily mapping Eclipse Platform's one. As example, if we consider file edition, many users like to just open a file and don't think about the concept of "project" whereas Eclipse Platform requires "projects". In this idea, the Eclipse Platform should try to integrate itself into user workflows as they're used to with other tools, rather than ignoring those workflows and forcing users to adopt Eclipse's specific ones only

I think this point can be part of  top level "improve usability" requirement


_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev


_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Mickael Istria-5
In reply to this post by Daniel Megert


On Wed, May 17, 2017 at 9:57 AM, Daniel Megert <[hidden email]> wrote:
I assume that you know there's File > Open File... Just wanted to mention it here for others.

What I have in mind is https://bugs.eclipse.org/bugs/show_bug.cgi?id=489799
Currently, if one does File > Open File... > MyClass.java, they get the JDT editor with very weak editor features, not much better than gedit or vim; because JDT only fully works with a project model well defined. In the case of opening a Java file in Eclipse IDE, what the users most likely want is rich Java edition, and the result of "Open File..." is not giving the rich edition they expect.
The idea is to implement what the user expects from "Open File...": rich edition, usually requiring project discovery.
FYI, VSCode Java plugin does that -discover the project model when opening a plain file to enable rich assist-; and the effect is that newcomers who don't know a thing about VSCode nor Eclipse IDE believe VSCode is better for Java because it has more features enabled after "Open File..."

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Angelo zerr
Hi all,

IMHO I think Eclipse should improve "Text" Editor with several features which it misses compare to VSCode editor:

 * async completion (I think Mickael have done work about that). After that I think completion should be opened every time when user is typing (like VSCode).
 * async hyperlink
 * async hover : today hover is displayed only when it is available, it should be better to show a "loading message" and when hover is available this "loading message" is replaced with hover.
 * CodeLens: I'm working on this topic and I can display "references" "implmentation" for TypeScript classes, vars, etc. You can find my My POC  at https://github.com/angelozerr/codelens-eclipse

Regard's Angelo

2017-05-17 11:28 GMT+02:00 Mickael Istria <[hidden email]>:


On Wed, May 17, 2017 at 9:57 AM, Daniel Megert <[hidden email]> wrote:
I assume that you know there's File > Open File... Just wanted to mention it here for others.

What I have in mind is https://bugs.eclipse.org/bugs/show_bug.cgi?id=489799
Currently, if one does File > Open File... > MyClass.java, they get the JDT editor with very weak editor features, not much better than gedit or vim; because JDT only fully works with a project model well defined. In the case of opening a Java file in Eclipse IDE, what the users most likely want is rich Java edition, and the result of "Open File..." is not giving the rich edition they expect.
The idea is to implement what the user expects from "Open File...": rich edition, usually requiring project discovery.
FYI, VSCode Java plugin does that -discover the project model when opening a plain file to enable rich assist-; and the effect is that newcomers who don't know a thing about VSCode nor Eclipse IDE believe VSCode is better for Java because it has more features enabled after "Open File..."

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev


_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Lars Vogel-2
 Hi Angelo,

sounds like great features.

> After that  I think completion should be opened every time when user is typing (like  VSCode).

I think that is Bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=348857, currently
targeted for 4.8 by the JDT team. Please comment in this bug, that you
also think that is important.

All the other features would be awesome to have, but we only at them
to the targets if someone plans to work on them. If you or someone
else plans to work on them, please open bugs and assign yourself.

It was never useful in the past to plan for a feature without
commitment from someone to work on it.

Best regards, Lars

At least JDT
On Fri, Jun 2, 2017 at 2:07 PM, Angelo zerr <[hidden email]> wrote:

> Hi all,
>
> IMHO I think Eclipse should improve "Text" Editor with several features
> which it misses compare to VSCode editor:
>
>  * async completion (I think Mickael have done work about that). After that
> I think completion should be opened every time when user is typing (like
> VSCode).
>  * async hyperlink
>  * async hover : today hover is displayed only when it is available, it
> should be better to show a "loading message" and when hover is available
> this "loading message" is replaced with hover.
>  * CodeLens: I'm working on this topic and I can display "references"
> "implmentation" for TypeScript classes, vars, etc. You can find my My POC
> at https://github.com/angelozerr/codelens-eclipse
>
> Regard's Angelo
>
> 2017-05-17 11:28 GMT+02:00 Mickael Istria <[hidden email]>:
>>
>>
>>
>> On Wed, May 17, 2017 at 9:57 AM, Daniel Megert <[hidden email]>
>> wrote:
>>>
>>> I assume that you know there's File > Open File... Just wanted to mention
>>> it here for others.
>>
>>
>> What I have in mind is
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=489799
>> Currently, if one does File > Open File... > MyClass.java, they get the
>> JDT editor with very weak editor features, not much better than gedit or
>> vim; because JDT only fully works with a project model well defined. In the
>> case of opening a Java file in Eclipse IDE, what the users most likely want
>> is rich Java edition, and the result of "Open File..." is not giving the
>> rich edition they expect.
>> The idea is to implement what the user expects from "Open File...": rich
>> edition, usually requiring project discovery.
>> FYI, VSCode Java plugin does that -discover the project model when opening
>> a plain file to enable rich assist-; and the effect is that newcomers who
>> don't know a thing about VSCode nor Eclipse IDE believe VSCode is better for
>> Java because it has more features enabled after "Open File..."
>>
>> _______________________________________________
>> platform-ui-dev mailing list
>> [hidden email]
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [hidden email], Web: http://www.vogella.com
_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Lars Vogel-2
In reply to this post by Mickael Istria-5
Hi Mickael,

I added some of your points to the target page, as I know you and
others are working (or planning to work) on them.

Best regards, Lars

On Wed, May 17, 2017 at 9:13 AM, Mickael Istria <[hidden email]> wrote:

> Hi Lars,
>
> I'd like to add a few items, not sure how to label and group them right now:
> * Enrich the generic editor: Add to the Generic Editor missing interesting
> features such as folding, aggregated hovers... (several bugs
> https://bugs.eclipse.org/bugs/buglist.cgi?classification=Eclipse&component=Text&list_id=16305519&product=Platform&query_format=advanced&resolution=---&short_desc=generic&short_desc_type=allwordssubstr
> )
> * Factorize common code features, commands and actions into a Language
> Toolkit: The idea is to have Platform UI/Text providing the definition of
> the very usual code-related commands, so each language could simply add
> handlers rather than redefining commands. That would also allow a better
> factorization of UI and shortcuts, and thus more consistency across plugins.
> * Provide "state of art" classes for Platform adopters: Currently, many
> classes have a lot of I<MyFeature>Extension<N> which provide additional
> value which is usually considered as "state of art" in modern IDEs. It's not
> easy for adopters to figure out the value provided by those extensions and
> to think about implementing them, and even to implement them. We should
> consider providing some "state of art" classes that take advantage of all
> extensions and  implements good default to minimize adoption. An important
> point is that we should design and document those classes as easily
> moveable, to easily allow us to add support for another extension without
> surprising users.
>
> _______________________________________________
> platform-ui-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: [hidden email], Web: http://www.vogella.com
_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|

Re: Planning for 4.8

Mickael Istria-5


On Tue, Aug 1, 2017 at 12:07 PM, Lars Vogel <[hidden email]> wrote:
Hi Mickael,

I added some of your points to the target page, as I know you and
others are working (or planning to work) on them.

Thank you. Those are indeed things that make sense as part of the Plan.
--
Mickael Istria
Eclipse IDE developer, at Red Hat Developers community

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev