Quantcast

Planning for 4.8

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
Loading...