Home » Eclipse Projects » Remote Application Platform (RAP) » [Discussion] RAP 1.4 planning
| [Discussion] RAP 1.4 planning [message #542660] |
Fri, 25 June 2010 14:41  |
|
Hi community,
we're currently making plans for RAP 1.4.
There are some architectural improvements that are necessary to be able
to push RAP to new horizons (such as this one: [1]). But apart from
this, the new release should, as always, also bring some new features
and improvements.
Therefore, we'd like to start a discussion about the most wanted plan
items. Of course, our resources are limited and we have to focus on the
most important and technically doable items.
What are the features that you'd like to see in the next release? What
are your pain points? Ideas?
Cheers and thanks for your help,
the RAP Team
[1]
http://eclipsesource.com/blogs/2010/06/11/writing-ipadiphone ipod-applications-with-swt/
|
|
| | | |
| Re: [Discussion] RAP 1.4 planning [message #543018 is a reply to message #542995] |
Mon, 28 June 2010 08:41  |
|
| Niels Lippke wrote on Mon, 28 June 2010 09:38 | Improvements for the tree widget would be nice. There are a lot of bugs related to it.
Regards,
Niels
|
I agree, I think in deed the Tree widget needs some reinplemting there are a lot of minor bugs that makes it look and feel difrent then the Tree Widget in RCP witch is not troublesome but in the end is not the goal of RAP.
I also think 1.4 should look in to updating the API's such as workbench etc. At the moment we work with 3.4 and I think upgrading such elements in the ends also improves the whole RAP experience. I don't know if its feasible to get all the functions but to gain the majority of such functions, makes the code reuse higher.
I also think the Upload widget and the War Deploy wizard will be a great addition to the whole RAP experience (from programmer view and from user view).
I think DrawD2 is an interesting feature but not something we should put every thing on. Upcoming technology like HTML5 don't have a enough penetration in company's just yet. Most company's use IE6 at the moment and I don't see that eny time soon unless Microsoft completely pulls the plug on that just yet. When it happens or if they implement HTML5 support in IE6 (witch still rules most of the browser market) I think DrawD2 will be a great adition.
Vertical text on widgets I think is only possible when we have Draw2d (that's how a.t.m. it works in Eclipse I think).
For the rest I think getting closer and closer to RCP functionality would be a good approach the problem is (for me) is that I don't know what is available and what is not. I often run in to it but I dont realy keep track. Maybe there should be some documentation on that 2.
With kind regards,
Martijn Cremer
hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
|
|
| | | |
| Re: [Discussion] RAP 1.4 planning [message #543067 is a reply to message #542809] |
Mon, 28 June 2010 10:28 |
|
Hi,
thanks for your input.
Tingel Christian wrote:
> The most important ones as I have seen:
>
> 1, Browser multi-tab support (The workaround there is not quite pragmatic);
could you explain in a few words what you would expect from a solution?
> 2, Upload widget;
that's one of the highest voted bugs, we'll likely take care of it.
> 3, Vertical texts on widget;
Can you explain your use case? How would you do this in SWT? Would the
transformation API in the GC help you?
> 4, Single source with Draw2d;
Yes, that's a frequent request, but also a huge effort.
Regards, Ralf
> Thanks and Best Regards!
>
> Yours: Tingel Christian~
|
|
| |
| Re: [Discussion] RAP 1.4 planning [message #543069 is a reply to message #543018] |
Mon, 28 June 2010 10:41 |
|
Hi Martijn,
thanks for your thoughts. Regarding your last point, how would the
suggested documentation look like? Our reasoning so far is that
switching the target and looking at the compile errors is much more
efficient than studying a documentation.
Regards, Ralf
Martijn Cremer wrote:
> Niels Lippke wrote on Mon, 28 June 2010 09:38
>> Improvements for the tree widget would be nice. There are a lot of
>> bugs related to it.
>>
>> Regards, Niels
>
>
> I agree, I think in deed the Tree widget needs some reinplemting there
> are a lot of minor bugs that makes it look and feel difrent then the
> Tree Widget in RCP witch is not troublesome but in the end is not the
> goal of RAP.
>
> I also think 1.4 should look in to updating the API's such as workbench
> etc. At the moment we work with 3.4 and I think upgrading such elements
> in the ends also improves the whole RAP experience. I don't know if its
> feasible to get all the functions but to gain the majority of such
> functions, makes the code reuse higher.
>
> I also think the Upload widget and the War Deploy wizard will be a great
> addition to the whole RAP experience (from programmer view and from user
> view).
>
> I think DrawD2 is an interesting feature but not something we should put
> every thing on. Upcoming technology like HTML5 don't have a enough
> penetration in company's just yet. Most company's use IE6 at the moment
> and I don't see that eny time soon unless Microsoft completely pulls the
> plug on that just yet. When it happens or if they implement HTML5
> support in IE6 (witch still rules most of the browser market) I think
> DrawD2 will be a great adition.
>
> Vertical text on widgets I think is only possible when we have Draw2d
> (that's how a.t.m. it works in Eclipse I think).
>
> For the rest I think getting closer and closer to RCP functionality
> would be a good approach the problem is (for me) is that I don't know
> what is available and what is not. I often run in to it but I dont realy
> keep track. Maybe there should be some documentation on that 2.
>
> With kind regards,
>
> Martijn Cremer
>
|
|
| |
| Re: [Discussion] RAP 1.4 planning [message #543086 is a reply to message #543069] |
Mon, 28 June 2010 11:17 |
|
Hi Ralf,
Well first off yeah, switching targets is a good way to find difference. And that's what I do al touch it could be made a bit more user friendly wouldn't hurt.
But that works great when your already working with the code. But when you start a project you plan it think up what you want in it from functionality point of view. At this stage your not working with the code just yet. So it would be nice to have a cheat sheet of what is available what's not.
So I think these options could be interesting:
- Quick Target switch, a simple drop down option menu in the Coolbar to switch targets faster. This would remove the Window -> Plugin Develpment -> Target platform interaction from the user end witch would make switching target platforms easier and more likely faster.
- The RAP/RCP validator, a simple validator that can be switch on when you create a project. This validator would (probebly at a push of the button you do not want it running constantly) validate the code against a another target (of your liking or set to default outside your normal target).
- Support matrix, a simple document that shows a matrix of API calls in the default RAP/RCP environment showing how far they are support (This would be in the Support documentation of RAP and searchable).
The switching target is not a real problem its more when you want to start a project you want to know what's possible and what's impossible just yet. No one can know all the functions of both platforms by hard they can have a good insight but knowing all is I think somting you do not want you want to know were you can look.
My suggestions are rough idea's and I hope they help.
With kind regards,
Martijn Cremer
| Ralf Sternberg wrote on Mon, 28 June 2010 12:41 | Hi Martijn,
thanks for your thoughts. Regarding your last point, how would the
suggested documentation look like? Our reasoning so far is that
switching the target and looking at the compile errors is much more
efficient than studying a documentation.
Regards, Ralf
Martijn Cremer wrote:
> Niels Lippke wrote on Mon, 28 June 2010 09:38
>> Improvements for the tree widget would be nice. There are a lot of
>> bugs related to it.
>>
>> Regards, Niels
>
>
> I agree, I think in deed the Tree widget needs some reinplemting there
> are a lot of minor bugs that makes it look and feel difrent then the
> Tree Widget in RCP witch is not troublesome but in the end is not the
> goal of RAP.
>
> I also think 1.4 should look in to updating the API's such as workbench
> etc. At the moment we work with 3.4 and I think upgrading such elements
> in the ends also improves the whole RAP experience. I don't know if its
> feasible to get all the functions but to gain the majority of such
> functions, makes the code reuse higher.
>
> I also think the Upload widget and the War Deploy wizard will be a great
> addition to the whole RAP experience (from programmer view and from user
> view).
>
> I think DrawD2 is an interesting feature but not something we should put
> every thing on. Upcoming technology like HTML5 don't have a enough
> penetration in company's just yet. Most company's use IE6 at the moment
> and I don't see that eny time soon unless Microsoft completely pulls the
> plug on that just yet. When it happens or if they implement HTML5
> support in IE6 (witch still rules most of the browser market) I think
> DrawD2 will be a great adition.
>
> Vertical text on widgets I think is only possible when we have Draw2d
> (that's how a.t.m. it works in Eclipse I think).
>
> For the rest I think getting closer and closer to RCP functionality
> would be a good approach the problem is (for me) is that I don't know
> what is available and what is not. I often run in to it but I dont realy
> keep track. Maybe there should be some documentation on that 2.
>
> With kind regards,
>
> Martijn Cremer
>
|
hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #543236 is a reply to message #543086] |
Mon, 28 June 2010 18:22 |
|
Thanks Martijn,
we'll discuss the documentation again. Regarding your ideas for tooling
enhancements, I'm afraid that those tasks would withdraw too much
valuable time from real RAP development. But this area is perfectly
suited for contributions from the community!
BTW, there will be per-project targets in Eclipse 3.7. Maybe this
feature helps to avoid some of the target switches and makes single
sourcing easier.
Regards, Ralf
Martijn Cremer wrote:
> Hi Ralf,
>
> Well first off yeah, switching targets is a good way to find difference.
> And that's what I do al touch it could be made a bit more user friendly
> wouldn't hurt.
>
> But that works great when your already working with the code. But when
> you start a project you plan it think up what you want in it from
> functionality point of view. At this stage your not working with the
> code just yet. So it would be nice to have a cheat sheet of what is
> available what's not.
> So I think these options could be interesting:
>
>
> Quick Target switch, a simple drop down option menu in the Coolbar to
> switch targets faster. This would remove the Window -> Plugin Develpment
> -> Target platform interaction from the user end witch would make
> switching target platforms easier and more likely faster.
> The RAP/RCP validator, a simple validator that can be switch on when you
> create a project. This validator would (probebly at a push of the button
> you do not want it running constantly) validate the code against a
> another target (of your liking or set to default outside your normal
> target). Support matrix, a simple document that shows a matrix of API
> calls in the default RAP/RCP environment showing how far they are
> support (This would be in the Support documentation of RAP and searchable).
>
>
> The switching target is not a real problem its more when you want to
> start a project you want to know what's possible and what's impossible
> just yet. No one can know all the functions of both platforms by hard
> they can have a good insight but knowing all is I think somting you do
> not want you want to know were you can look.
>
> My suggestions are rough idea's and I hope they help.
>
> With kind regards,
>
> Martijn Cremer
>
>
> Ralf Sternberg wrote on Mon, 28 June 2010 12:41
>> Hi Martijn,
>>
>> thanks for your thoughts. Regarding your last point, how would the
>> suggested documentation look like? Our reasoning so far is that
>> switching the target and looking at the compile errors is much more
>> efficient than studying a documentation.
>>
>> Regards, Ralf
>>
>> Martijn Cremer wrote:
>> > Niels Lippke wrote on Mon, 28 June 2010 09:38
>> >> Improvements for the tree widget would be nice. There are a lot of
>> >> bugs related to it.
>> >>
>> >> Regards, Niels
>> > > > I agree, I think in deed the Tree widget needs some reinplemting
>> there
>> > are a lot of minor bugs that makes it look and feel difrent then the
>> > Tree Widget in RCP witch is not troublesome but in the end is not the
>> > goal of RAP.
>> > > I also think 1.4 should look in to updating the API's such as
>> workbench
>> > etc. At the moment we work with 3.4 and I think upgrading such elements
>> > in the ends also improves the whole RAP experience. I don't know if its
>> > feasible to get all the functions but to gain the majority of such
>> > functions, makes the code reuse higher.
>> > > I also think the Upload widget and the War Deploy wizard will be a
>> great
>> > addition to the whole RAP experience (from programmer view and from
>> user
>> > view).
>> > > I think DrawD2 is an interesting feature but not something we
>> should put
>> > every thing on. Upcoming technology like HTML5 don't have a enough
>> > penetration in company's just yet. Most company's use IE6 at the moment
>> > and I don't see that eny time soon unless Microsoft completely pulls
>> the
>> > plug on that just yet. When it happens or if they implement HTML5
>> > support in IE6 (witch still rules most of the browser market) I think
>> > DrawD2 will be a great adition.
>> > > Vertical text on widgets I think is only possible when we have Draw2d
>> > (that's how a.t.m. it works in Eclipse I think).
>> > > For the rest I think getting closer and closer to RCP functionality
>> > would be a good approach the problem is (for me) is that I don't know
>> > what is available and what is not. I often run in to it but I dont
>> realy
>> > keep track. Maybe there should be some documentation on that 2.
>> > > With kind regards,
>> > > Martijn Cremer
>> >
>
>
|
|
| |
| Re: [Discussion] RAP 1.4 planning [message #543389 is a reply to message #542660] |
Tue, 29 June 2010 09:40 |
|
Ralf,
Would the RAP protocol also enable to have a better Event handling? I mean at this moment the Event.doit boolean has no real meaning in Events seeing that the communication back to the interface of the user cant undo such an event. I see that the RAP protocol could fill this little gap.
hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #543410 is a reply to message #542660] |
Tue, 29 June 2010 10:52 |
 Markus rüger
Messages: 369
Registered: July 2009 |
Senior Member |
|
|
Hi RAP Team,
here are my suggestions:
1. New Workbench Code of 3.6 to hide editors per perspective (I know it is
already in 3.5, but why implement 3.5 if
3.6 is already there?)
2. Moveable/Draggable Views
3. More enhancements and fixings on tree (but noticed that this is already
in work)
4. Session kill mechanism on browser close
We currently use the draft from bug 284273, which eliminates alot, but
not all cases.
5. Bug 256133, which sometimes cause probles in our app
6. All other bugs ;-)
That's it, at least for now :-)
Regards,
Markus
"Ralf Sternberg" <rsternberg@eclipsesource.com> schrieb im Newsbeitrag
news:i02f61$ecf$1@build.eclipse.org...
> Hi community,
>
> we're currently making plans for RAP 1.4.
>
> There are some architectural improvements that are necessary to be able
> to push RAP to new horizons (such as this one: [1]). But apart from
> this, the new release should, as always, also bring some new features
> and improvements.
>
> Therefore, we'd like to start a discussion about the most wanted plan
> items. Of course, our resources are limited and we have to focus on the
> most important and technically doable items.
>
> What are the features that you'd like to see in the next release? What
> are your pain points? Ideas?
>
> Cheers and thanks for your help,
>
> the RAP Team
>
> [1]
> http://eclipsesource.com/blogs/2010/06/11/writing-ipadiphone ipod-applications-with-swt/
|
|
| | | | | |
| Re: [Discussion] RAP 1.4 planning [message #543528 is a reply to message #543067] |
Tue, 29 June 2010 17:06 |
tingel christian
Messages: 46
Registered: December 2009 |
Member |
|
|
Hi, Ralf:
Sorry for my so late response~
>> 1, Browser multi-tab support (The workaround there is not quite pragmatic);
>could you explain in a few words what you would expect from a solution?
I had a comment here before:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285398
In my case(and probably in some other mates' cases), what we need is just the point.for example:users can start a session with a certain account logged in for some special work, and then open a new tab to start another session with a different account logged in to do some other works~~~
Yes, there is a solution there in the above url, but, I am sorry to say, it requires us to make some modification to the web container of our clients, however, we can not predict what web container will our client use. Jetty, Tomcat, Weblogic...too many options...So, we really wish that the problem could be solved from within the RAP framework itself.
>> 3, Vertical texts on widget;
>Can you explain your use case? How would you do this in SWT? Would the
transformation API in the GC help you?
I am sorry to say but I am not quite sure about the meaning of "the transformation API", could you please explain the name of the method?thanks!
According to the use case...Here is an example:
http://www.eettaiwan.com/STATIC/ARTICLE_IMAGES/200811/0811B_ DC4_F3.jpg
In this case, the letters are vertically layouted, and also, every letter there is rotated;
but there is another scene when we need to write East Asian characters there, the total string is required to be layouted vertically but every letter should not be rotated
I hope I expressed myself clearly... 
Thanks and Best Regards!
Yours: Tingel Christian
| Ralf Sternberg wrote on Mon, 28 June 2010 18:28 | Hi,
thanks for your input.
Tingel Christian wrote:
> The most important ones as I have seen:
>
> 1, Browser multi-tab support (The workaround there is not quite pragmatic);
could you explain in a few words what you would expect from a solution?
> 2, Upload widget;
that's one of the highest voted bugs, we'll likely take care of it.
> 3, Vertical texts on widget;
Can you explain your use case? How would you do this in SWT? Would the
transformation API in the GC help you?
> 4, Single source with Draw2d;
Yes, that's a frequent request, but also a huge effort.
Regards, Ralf
> Thanks and Best Regards!
>
> Yours: Tingel Christian~
|
[Updated on: Tue, 29 June 2010 17:08] Report message to a moderator |
|
| | |
| Re: [Discussion] RAP 1.4 planning [message #543689 is a reply to message #543454] |
Wed, 30 June 2010 09:51 |
Niels Lippke
Messages: 71
Registered: December 2009 |
Member |
|
|
Sorry,
I meant JFace Tooltips and created Bug #318427 as an enhancement request.
Thanks, Niels
"Benjamin Muskalla" <bmuskalla@eclipsesource.com> schrieb im Newsbeitrag
news:i0crup$5eo$4@build.eclipse.org...
> Hi Niels,
>
> with custom tooltip support, to what are you referring? JFace Tooltips or
> better theming possibilities for the tooltips?
> Either way, feel free to open feature requests.
>
> Regards,
> Ben
>
> Niels Lippke wrote:
>> Hi,
>>
>> I also stumbeled across the missing custom tooltip support. Don't know
>> wether this is hard work or not, but it would
>> a) improve single sourcing
>> b) make applications more conventient
>>
>> Regards, Niels
>
>
> --
> Benjamin Muskalla | EclipseSource Karlsruhe
> http://www.eclipsesource.com | http://twitter.com/eclipsesource
|
|
| |
| Re: [Discussion] RAP 1.4 planning [message #544011 is a reply to message #543528] |
Thu, 01 July 2010 10:32 |
|
Hi,
Tingel Christian wrote:
>>> 1, Browser multi-tab support (The workaround there is not quite
>>> pragmatic);
>> could you explain in a few words what you would expect from a solution?
> I had a comment here before:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285398
> In my case(and probably in some other mates' cases), what we need is
> just the point.for example:users can start a session with a certain
> account logged in for some special work, and then open a new tab to
> start another session with a different account logged in to do some
> other works~~~
> Yes, there is a solution there in the above url, but, I am sorry to say,
> it requires us to make some modification to the web container of our
> clients, however, we can not predict what web container will our client
> use. Jetty, Tomcat, Weblogic...too many options...So, we really wish
> that the problem could be solved from within the RAP framework itself.
There are two different issues. First, you don't want to tweak the
servlet container. You're right, another solution would be necessary to
allow tabbed browsing out of the box.
The second is that for your requirement (different logins in different
tabs), you would have to bind the login to the SessionStore, not to the
HttpSession (as you probably do already). This is possible with both
Stefan's and a potential out-of-the-box solution.
>>> 3, Vertical texts on widget;
>> Can you explain your use case? How would you do this in SWT? Would the
> transformation API in the GC help you?
> I am sorry to say but I am not quite sure about the meaning of "the
> transformation API", could you please explain the name of the
> method?thanks!
GC allows you to draw on a Canvas widget. With transformations, text can
also be rotated. See GC#setTransform() in SWT.
I think you should first think about how you could solve your problem
with SWT. If there are just a few vertical texts, images might be an
option. Otherwise GC seems to be the only way to go.
Best regards, Ralf
|
|
| | | | | |
| Re: [Discussion] RAP 1.4 planning [message #549077 is a reply to message #542660] |
Sat, 24 July 2010 03:35 |
|
Hi RAP Team,
How about to be able to run RAP JUnit headlessly ?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=293751
Best Regards,
Setya
> Hi community,
>
> we're currently making plans for RAP 1.4.
>
> There are some architectural improvements that are necessary to be able
> to push RAP to new horizons (such as this one: [1]). But apart from
> this, the new release should, as always, also bring some new features
> and improvements.
>
> Therefore, we'd like to start a discussion about the most wanted plan
> items. Of course, our resources are limited and we have to focus on the
> most important and technically doable items.
>
> What are the features that you'd like to see in the next release? What
> are your pain points? Ideas?
>
> Cheers and thanks for your help,
>
> the RAP Team
>
> [1]
> http://eclipsesource.com/blogs/2010/06/11/writing-ipadiphone ipod-applications-with-swt/
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #549262 is a reply to message #548545] |
Mon, 26 July 2010 10:13 |
|
Hi Thomas,
we cannot add functionality to RWT that does not exist in SWT.
The workaround for SWT is to draw the texts in the Table all by yourself
using a paint listener. From my point of view, this must be considered
rather a hack than a solution. Maybe this could even become possible
with RAP if we extends the GC support - however, I'd tend to use a
custom widget for RAP since I doubt that this hack would perform well.
Best regards, Ralf
Thomas wrote:
> Hi,
>
> would it be possible to add multiline-support for tables? Our customer
> explicitly mentioned the need for multiline-entries in our RAP-project.
> All entries in the different fora resulting in >>there's a workaround
> for swt but no way with actual rwt<<
> (We solved it in a very ugly way with urgent need for improvement)
>
> Regards
> Thomas
>
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #549264 is a reply to message #548816] |
Mon, 26 July 2010 10:20 |
|
Hi,
we realize that support for mobile devices is getting more and more
important and decided to work on resolving bugs on those platforms. So
please simply open bugs for problems you experience, preferably
including snippets, screenshots, etc.
Regards, Ralf
Martijn Cremer wrote:
> Jesus Roberto Luna Quiroga wrote on Fri, 23 July 2010 01:21
>> Hi, we have an ERP based on RCP for hotels and we're planning to make
>> it available for smartphones as for browsers.
>>
>> But it seems that RAP has issues with smartphones as this link
>> http://old.nabble.com/%28multi-%29touch-panels,-iPhone,-iPad
>> -et-cetera-td29215797.html quotes.
>>
>> We would like to see more improvements regarding this.
>
>
> Jesus,
>
> I think the RAP protocol will make life easier, there is a blog post out
> there about using RAP on a Iphone
> ( http://eclipsesource.com/blogs/2010/06/11/writing-ipadiphone ipod-applications-with-swt/)
> witch shows promise. I don't know if the RAP team actually will focus on
> the Smartphones or first implement the RAP protocol etc..
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #549349 is a reply to message #542660] |
Mon, 26 July 2010 13:42 |
|
Hi all,
thanks for your input to our planning for the next release. Meanwhile,
we discussed our plans for 1.4 and would like to let you know about our
progress. Please note that this is only a preliminary plan, we didn't
make the final decision yet.
Here are the overall themes we'd like to address in RAP 1.4:
* Widget improvements and additions
As in every RAP release, we will improve our widget set. A new Tree
implementation is already in CVS. Non-native scrollbars would be another
improvement. There is a great demand for the upload widget, and we'd
like to integrate it into the release.
To support custom widgets better, we'd also like to come up with a small
documented client API for custom widgets.
* Theming & Design
We want to further improve the look and feel of RAP applications by
adding more theming features like shadows and more animations.
Our aging default theme also needs a fresh look.
Those widgets that are not very customizeable by theming, should be
improved. We will also ease the theming of custom widgets.
* Single Sourcing
To support single sourcing, we will update the Eclipse UI APIs to 3.7
and add more Eclipse API to RAP - first and foremost key bindings, as
there is a great demand.
* Support for other client technologies / Mobile
We see that mobile devices are getting more and more important and thus
want to improve RAP on those devices. For a start, we will fix blocking
bugs on iPhone/iPad and on Adroid.
Moreover, we will work towards a well-defined protocol between client
and server that will once allow for exchangeable client implementations.
* Reliability, Scalability and Availability
We want to further improve the performance of RAP by reducing the client
footprint.
We are involved in a research project that evaluates solutions for
transparent failover.
* Integration with other Eclipse projects
In the last release, we worked with EMF and Riena to make RAP usable
with these projects. We want to follow up this effort and will also have
a look at Virgo.
* Tooling
Two Google Summer of Code projects will be integrated into the RAP
tooling: The WAR Export and the Theme Editor.
That's it. You'll miss Draw2D on this list. We recognized that there is
a great interest in this feature and we did look into it try to come up
with an estimation. Draw2D alone would be a huge effort and we currently
cannot afford it to do that with the resources we have for OpenSource
development. GEF would require even more work. We're currently thinking
about a commercial offering for Draw2D/GEF if there's enough interest.
Cheers,
The RAP Team
|
|
|
| Re: [Discussion] RAP 1.4 planning [message #549380 is a reply to message #548548] |
Mon, 26 July 2010 14:08 |
|
Hi Philipp,
Philipp Eichhorn wrote:
> I would like to see some investigation and progress concerning the
> StyledText.
StyledText would be an interesting challenge for us, too. But since
there were hardly any interest in it so far, we decided to keep this
feature off of our plan for 1.4, in favor of more requested features.
Maybe next year...
Best regards, Ralf
|
|
| |
Goto Forum:
Current Time: Mon Dec 30 16:20:10 GMT 2024
Powered by FUDForum. Page generated in 0.05125 seconds |
] 
Search
Help
Register
Login
Home
