Home » General (non-technical) » Eclipse Foundation » Eclipse Themes and Priorities
|
| Re: Eclipse Themes and Priorities [message #8718 is a reply to message #8661] |
Thu, 23 December 2004 01:46   |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
Mike Milinkovich wrote:
> The Eclipse Development Process establishes the Requirements Council and
> gives that group the responsibility for establishing "themes and priorities"
> for development planning across the many Eclipse projects. The group's final
> draft can be found at
> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>
> Please note that the main purpose of the document is to establish a common
> set of themes and priorities for use across the many projects at Eclipse. It
> is hoped that individual projects will use a subset of these T&P's so that
> we have some consistency across the community. But individual projects also
> have the freedom to add their own if they feel that their needs are not met.
>
> As always, comments are appreciated.
It is important to realize, that many of the TP-documents content
indicates the need of a dedicated project, similar to the one suggested
here:
[PROJECT] - Collaboration and Government Infrastructure (CAGI)
http://www.eclipse.org/newsportal/article.php?id=20&grou p=eclipse.foundation
> /mike
..
--
http://lazaridis.com
|
|
| |
| Re: Eclipse Themes and Priorities [message #10013 is a reply to message #9991] |
Wed, 12 January 2005 23:03 |
| Eclipse User |
|
|
|
Originally posted by: myersj.nospam.gmail.com
Dean wrote:
> As part of the "Scale Up" theme, it would be good if SWT were ported to
> 64bit (Windows, Linux, etc.) to make it more suitable for
> scientific/technical applications.
>
FYI: SWT has already been ported to Linux/GTK 2 on AMD 64 and IA 64.
See the download page for Eclipse 3.0.1:
http://download.eclipse.org/downloads/drops/R-3.0.1-20040916 1125/index.php
(not sure why there aren't regular builds of IA 64 for the 3.1 Milestones)
This isn't officially supported yet, but many people are happily running
on Linux and AMD 64.
- Jeff
|
|
| |
| Re: Eclipse Themes and Priorities [message #11793 is a reply to message #8661] |
Mon, 17 January 2005 16:44 |
| Eclipse User |
|
|
|
Originally posted by: giribet.daniel.edu.upf
IMHO the MacOSX Eclipse version should be mentioned at least in passing in
the section "Improve consistency among implementations on Windows and
Linux" of the draft. I am appalled to imply from the document that there
are more downloads for the HP-UX version than for the MacOSX version. It
might be true but maybe MacOSX should be placed last anyway?
Personally, I use Eclipse daily in my MacOSX box for any Java and XML
development and have found the fact of having the same dev. environment on
any platform to be *very valuable*.
I humbly think that the MacOSX port should be taken some consideration, or
at least mentioned in passing. Are there any plans on ongoing support on
this platform? This would fit in the "Appealing to the Broader Community"
theme.
On the other hand, I would very much love to be able to use the VE and
other EMF and GEF-based projects in MacOSX. Maybe the VE porting problems
are related to these underlying frameworks? If so, any work done on them in
MacOSX would benefit other projects as well as VE. I remember running VE in
OSX in the days before the VE page was updated saying MacOSX was not
supported and it nearly ran OK (there were some drawing glitches mainly).
The latest versions throw an exception and fail, though.
Thanks and kudos for the great job that is Eclipse!
(PS: incidentally, there are some mentions of Eclipse running on a 64-bit
OS, actually, MacOSX on a G5 should qualify ^_^)
--
Daniel Giribet Farr
|
|
| |
| Re: Eclipse Themes and Priorities [message #12875 is a reply to message #12863] |
Fri, 21 January 2005 23:04 |
 Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Genady,
Thanks for the comments.
Regarding the number of projects at Eclipse, that's a really good question.
It certainly doesn't hurt every once in a while to go back to first
principles.
First, Eclipse has always been about more languages and platforms than Java
alone. That was one of the reasons why Eclipse built SWT rather than going
with Swing. There have been multiple projects at Eclipse almost from the
first day.
So the goal of Eclipse is to be a development platform --- not just a Java
IDE. Although we are best known for it, Eclipse is not a Java IDE. It is an
open source community.
I personally don't mind if occasionally a project fails. If you don't fail
once in a while, you're not trying.
As for the specific example you raised, I think you're dead wrong about
CDT's success and its potential for the future. CDT is being used by many
RTOS vendors as their IDE. It is shipping with the RedHat and Suse Linux
distro's. And there are lots of great things coming down the pipe for it. I
actually think it has been a big success.
"Genady" <eclipse@genady.org> wrote in message
news:csr8m5$5rt$1@www.eclipse.org...
>I would like to add the following issues that IMHO should be addressed:
> 1. Ease of installation and easy learning curve (similar to section 6 in
> the document, but focus on installation).
> I thinks that installation of new plugins can be made easier for the end
> users.
> 2. Provide more "ready to use" SWT widgets/JFace components. Many times I
> really miss the flexibility I had in Swing.
> 3. Develop UI testing framework (if it does not exist already)
>
> It's funny to say that, but I feel that there are so many projects
> developed under the Eclipse "umbrella" that it's hard
> for me to keep track. Maybe somebody can clarify the goals of "Eclipse" in
> creating so many projects. As an example,
> the CDT project didn't become a major player in the C/C++ development area
> (as opposed to JDT).
> Wouldn't it be better to allocate more resources in order to create one
> very successful project, that (in this
> case) can become the base for creation of many other projects (as it is
> with JDT), rather than having many
> small projects, that some of them will never mature and benefit the
> community?
>
> Genady
>
> Mike Milinkovich wrote:
>
>>The Eclipse Development Process establishes the Requirements Council and
>>gives that group the responsibility for establishing "themes and
>>priorities" for development planning across the many Eclipse projects. The
>>group's final draft can be found at
>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>
>>Please note that the main purpose of the document is to establish a common
>>set of themes and priorities for use across the many projects at Eclipse.
>>It is hoped that individual projects will use a subset of these T&P's so
>>that we have some consistency across the community. But individual
>>projects also have the freedom to add their own if they feel that their
>>needs are not met.
>>
>>As always, comments are appreciated.
>>
>>/mike
>>
>>Mike Milinkovich
>>Executive Director
>>Eclipse Foundation
>>
>>
>>
>>
>>
|
|
|
| Re: Eclipse Themes and Priorities [message #12931 is a reply to message #12875] |
Sat, 22 January 2005 08:36 |
Genady Beryozkin
Messages: 410
Registered: July 2009 |
Senior Member |
|
|
Mike Milinkovich wrote:
>Genady,
>
>Thanks for the comments.
>
>Regarding the number of projects at Eclipse, that's a really good question.
>It certainly doesn't hurt every once in a while to go back to first
>principles.
>
>First, Eclipse has always been about more languages and platforms than Java
>alone. That was one of the reasons why Eclipse built SWT rather than going
>with Swing. There have been multiple projects at Eclipse almost from the
>first day.
>So the goal of Eclipse is to be a development platform --- not just a Java
>IDE. Although we are best known for it, Eclipse is not a Java IDE. It is an
>open source community.
>
>I personally don't mind if occasionally a project fails. If you don't fail
>once in a while, you're not trying.
>
>
>
As long as the live/dead ratio is good and this is also result from
resource allocation.
I think that the great success of JDT is partially due to the support it
got from IBM. I'm sure not all projects
can receive such attention (either from IBM or other companies), so I
hope and believe resources are allocated thoughtfully.
I also feel that because there are so many projects I cannot check them
all to really understand what they are about or whether they are mature
enough to be used in commercial environment (My employer cannot let me
contribute code, but I try to do that privately).
Maybe there should be the "front line" of mature projects (such as
Platform/RCP, JDT, CDT) and what IBM called
"alphaworks". Part of that confusion leads to the problems with the
download page layout (see other thread in this group) -
"How can you tell the users what they should download".
>As for the specific example you raised, I think you're dead wrong about
>CDT's success and its potential for the future. CDT is being used by many
>RTOS vendors as their IDE. It is shipping with the RedHat and Suse Linux
>distro's. And there are lots of great things coming down the pipe for it. I
>actually think it has been a big success.
>
>
>
I have been following CDT project since its creation and checked in once
in a while. I've last checked CDT few months ago and I will definitely
look at it again. I believe it cannot compete with VisualStudio on the
Windows platform and on Unix, it suffers from various look and feel
problems (discussed elsewhere).
Maybe there should be an effort to develop a new SWT implementation
based on toolkits other than GTK (e.g., qt). I know there are license
incompatibilities but can you tell me what's wrong with the following
scenario:
* Eclipse ships as usual on all platforms with current SWT implementations
* An independent group of developers develops qt-based implementation
and publishes it under the appropriate license
* Users download the qt implementation of SWT, install it on their
machine and Eclipse will pick it up.
This is similar to GPL applications for Windows - Using such
applications does not force Windows to be licensed under GPL.
Genady
>
>
|
|
|
| Re: Eclipse Themes and Priorities [message #12988 is a reply to message #12875] |
Sat, 22 January 2005 14:47 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
You are talking of projects that are not succesfull, but what about the
projects that are dead / inactive ?
I think they are much more disturbing.
What about having an activity rate, or simply an inactive section where
projects could be moved by the webmaster.
PaScaL
Mike Milinkovich wrote:
> Genady,
>
> Thanks for the comments.
>
> Regarding the number of projects at Eclipse, that's a really good question.
> It certainly doesn't hurt every once in a while to go back to first
> principles.
>
> First, Eclipse has always been about more languages and platforms than Java
> alone. That was one of the reasons why Eclipse built SWT rather than going
> with Swing. There have been multiple projects at Eclipse almost from the
> first day.
>
> So the goal of Eclipse is to be a development platform --- not just a Java
> IDE. Although we are best known for it, Eclipse is not a Java IDE. It is an
> open source community.
>
> I personally don't mind if occasionally a project fails. If you don't fail
> once in a while, you're not trying.
>
> As for the specific example you raised, I think you're dead wrong about
> CDT's success and its potential for the future. CDT is being used by many
> RTOS vendors as their IDE. It is shipping with the RedHat and Suse Linux
> distro's. And there are lots of great things coming down the pipe for it. I
> actually think it has been a big success.
>
>
> "Genady" <eclipse@genady.org> wrote in message
> news:csr8m5$5rt$1@www.eclipse.org...
>
>>I would like to add the following issues that IMHO should be addressed:
>>1. Ease of installation and easy learning curve (similar to section 6 in
>>the document, but focus on installation).
>>I thinks that installation of new plugins can be made easier for the end
>>users.
>>2. Provide more "ready to use" SWT widgets/JFace components. Many times I
>>really miss the flexibility I had in Swing.
>>3. Develop UI testing framework (if it does not exist already)
>>
>>It's funny to say that, but I feel that there are so many projects
>>developed under the Eclipse "umbrella" that it's hard
>>for me to keep track. Maybe somebody can clarify the goals of "Eclipse" in
>>creating so many projects. As an example,
>>the CDT project didn't become a major player in the C/C++ development area
>>(as opposed to JDT).
>>Wouldn't it be better to allocate more resources in order to create one
>>very successful project, that (in this
>>case) can become the base for creation of many other projects (as it is
>>with JDT), rather than having many
>>small projects, that some of them will never mature and benefit the
>>community?
>>
>>Genady
>>
>>Mike Milinkovich wrote:
>>
>>
>>>The Eclipse Development Process establishes the Requirements Council and
>>>gives that group the responsibility for establishing "themes and
>>>priorities" for development planning across the many Eclipse projects. The
>>>group's final draft can be found at
>>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>>
>>>Please note that the main purpose of the document is to establish a common
>>>set of themes and priorities for use across the many projects at Eclipse.
>>>It is hoped that individual projects will use a subset of these T&P's so
>>>that we have some consistency across the community. But individual
>>>projects also have the freedom to add their own if they feel that their
>>>needs are not met.
>>>
>>>As always, comments are appreciated.
>>>
>>>/mike
>>>
>>>Mike Milinkovich
>>>Executive Director
>>>Eclipse Foundation
>>>
>>>
>>>
>>>
>>>
>
>
>
|
|
| |
| Re: Eclipse Themes and Priorities [message #13077 is a reply to message #12931] |
Sat, 22 January 2005 18:17 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
I *suspect* (don't know for sure) that you may misunderstand how resources
get allocated at Eclipse (and it most open source projects). If you think
that the Foundation or its Executive Director allocates resources across the
projects, you are mistaken. The people who work on the projects are the ones
who *want* to work on it, or who have been asked to work on it by their
employers (and hopefully they enjoy doing so!).
So the way to get more resources working on a project is to recruit more
developers to work on Eclipse projects. And hopefully some of them are
interested in those areas which need the additional people.
I do like your idea about having some indication of the project maturity. I
need to think about how to do that a little more deeply. I don't think that
it is as simple as fixing the download page. Some sort of community-based
rating system feels closer to me.
Regarding the Qt licensing issues, what you are proposing could perhaps
work, but IANAL.
"Genady" <eclipse@genady.org> wrote in message
news:cst3b5$3f8$1@www.eclipse.org...
> As long as the live/dead ratio is good and this is also result from
> resource allocation.
> I think that the great success of JDT is partially due to the support it
> got from IBM. I'm sure not all projects
> can receive such attention (either from IBM or other companies), so I hope
> and believe resources are allocated thoughtfully.
>
> I also feel that because there are so many projects I cannot check them
> all to really understand what they are about or whether they are mature
> enough to be used in commercial environment (My employer cannot let me
> contribute code, but I try to do that privately).
> Maybe there should be the "front line" of mature projects (such as
> Platform/RCP, JDT, CDT) and what IBM called
> "alphaworks". Part of that confusion leads to the problems with the
> download page layout (see other thread in this group) -
> "How can you tell the users what they should download".
>
>>As for the specific example you raised, I think you're dead wrong about
>>CDT's success and its potential for the future. CDT is being used by many
>>RTOS vendors as their IDE. It is shipping with the RedHat and Suse Linux
>>distro's. And there are lots of great things coming down the pipe for it.
>>I actually think it has been a big success.
>>
>>
> I have been following CDT project since its creation and checked in once
> in a while. I've last checked CDT few months ago and I will definitely
> look at it again. I believe it cannot compete with VisualStudio on the
> Windows platform and on Unix, it suffers from various look and feel
> problems (discussed elsewhere).
>
> Maybe there should be an effort to develop a new SWT implementation based
> on toolkits other than GTK (e.g., qt). I know there are license
> incompatibilities but can you tell me what's wrong with the following
> scenario:
> * Eclipse ships as usual on all platforms with current SWT implementations
> * An independent group of developers develops qt-based implementation and
> publishes it under the appropriate license
> * Users download the qt implementation of SWT, install it on their machine
> and Eclipse will pick it up.
>
> This is similar to GPL applications for Windows - Using such applications
> does not force Windows to be licensed under GPL.
>
> Genady
>
>>
|
|
|
| Re: Eclipse Themes and Priorities [message #13190 is a reply to message #13077] |
Sat, 22 January 2005 21:01 |
Genady Beryozkin
Messages: 410
Registered: July 2009 |
Senior Member |
|
|
Mike Milinkovich wrote:
>I *suspect* (don't know for sure) that you may misunderstand how resources
>get allocated at Eclipse (and it most open source projects). If you think
>that the Foundation or its Executive Director allocates resources across the
>projects, you are mistaken. The people who work on the projects are the ones
>who *want* to work on it, or who have been asked to work on it by their
>employers (and hopefully they enjoy doing so!).
>
(It turned into something longer than I initially intended ...)
There are two separate issues. If I don't mistake (please correct me if
I'm wrong) there are few companies that
"contribute" their employees to work on the various projects, with
probably IBM being the most dominant contributor.
I'm sorry to get back to the CDT project, but initially it was developed
by IBM employees, and at that point of time,
I can say with confidence, that I would rather see more useful features
in JDT rather than a brand new but unpolished C++ IDE
that was hardly usable (believe me, I spent a lot of time trying to use
it). That decision was of course internal to IBM and I cannot expect IBM
to follow my advice (at least as long as I don't work for them), but
maybe it could hear the advice of somebody else (e.g., the
board/community/you). That other person could tell IBM - "It's really
nice that you want to start another project, but do you mind helping us
with project XXXX first?". Having *too many* unsuccessful projects (and
I don't say there are too many of them now, I just say there are too
many projects in general) doesn't make any good to the Eclipse project
as a whole. That brings me to the second issue.
The second issue is - does the eclipse project have a strategy, and what
that strategy is? Being a JCP member I follow
the JCP process and the JSRs that go through it. It looks like Sun
governs the JCP process (with a right to veto decisions and only few
other members in the executive committees)
to fit into its strategic goals (as manufacturer of hardware, software,
provider of services or whatever these goals are). I disagree with that
goal as I see it, but at least it's strategy, and it is clear for me,
for example, why Sun invests in J2EE (it helps selling pricey tools and
servers) and invests much less in Java on the desktop (Sun does not make
Windows or PCs). The difference between Swing and SWT tells it all.
From what you describe any company that joins the eclipse board can
start a new project to support their favorite product (few companies are
truly philanthropic).
Suppose I pay the membership fee, does that mean I can develop the new
OS for my teapot as Eclipse project?
I may be totally wrong about it, mainly because I didn't follow the
formation of the consortium/board/etc. I'll be glad if you
provide some pointers to relevant information.
The statement that the people who work on the projects are the ones who
want to work on it is only 90% true. That is, it is true for committers,
but contributions from the broad audience must be first accepted by the
project committers (who are usually employees of commercial companies,
but that is irrelevant in this discussion) and I'm not sure what are the
criteria of whether such contributions are reviewed and finally
committed. For example, in early 2004 I had a (quite unpleasant)
experience when I tried to contribute the autoboxing compiler code for
the JDK1.5 effort (my largest attempt so far). I have spent more than a
month of net work, studying the compiler internals, writing and testing
the code (of course coordinated with the relevant committer).
Eventually, the contribution was not accepted. Some reasons are clear
and understandable, while some others are not.
Genady
|
|
| |
| Re: Eclipse Themes and Priorities [message #13246 is a reply to message #13190] |
Sun, 23 January 2005 17:04 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Genay,
I started to write a very long answer to this, but I stopped. I was
basically re-writing tons of information which is available on the website
elsewhere.
Here is a sampling of pages you may want to read.
1. Eclipse Development Process at
http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf
2. The Eclipse Councils at http://www.eclipse.org/org/council.html. Take a
look at the Themes and Priorities document, and keep an eye out for the
upcoming Planning and Architecture documents.
3. You may be interested in just reading the "Purposes" section of our
bylaws at
http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf
I think that we are going to have to agree to disagree on the notion that
there are too many projects. We are hoping to add more. Eclipse has *never*
been about just the Java IDE. It has always been about building a
development platform targeted at many problem domains. In the case of CDT, I
am sorry that it did not meet your expectations, but in my mind the solution
is to recruit more developers to add resources to it.
Eclipse does have a strategy. Much of which is embodied in the documents
above. More documentation is coming in the form of the Eclipse Roadmap
document which is going to be completed by the end of Feb.
I personally am uncomfortable with any comparison of Eclipse and the JCP.
The JCP is a standard organization led by one vendor. Eclipse is an open
source community led by a Foundation which has many members.
As to accepting contributions, those decisions reside completely with the
project and its committers. I don't know the history your attempt, but I can
only assume that the responsible committers had valid reasons. That does not
necessarily mean there was anything wrong with your contribution. There
could be a myriad of reasons such as risk, backwards compatibility, or
synergy with future directions why a contribution may not work out. But I
believe that is true of every open source project, not just Eclipse.
"Genady" <eclipse@genady.org> wrote in message
news:csuevo$iit$1@www.eclipse.org...
>
> Mike Milinkovich wrote:
>
>>I *suspect* (don't know for sure) that you may misunderstand how resources
>>get allocated at Eclipse (and it most open source projects). If you think
>>that the Foundation or its Executive Director allocates resources across
>>the projects, you are mistaken. The people who work on the projects are
>>the ones who *want* to work on it, or who have been asked to work on it by
>>their employers (and hopefully they enjoy doing so!).
>>
> (It turned into something longer than I initially intended ...)
>
> There are two separate issues. If I don't mistake (please correct me if
> I'm wrong) there are few companies that
> "contribute" their employees to work on the various projects, with
> probably IBM being the most dominant contributor.
> I'm sorry to get back to the CDT project, but initially it was developed
> by IBM employees, and at that point of time,
> I can say with confidence, that I would rather see more useful features in
> JDT rather than a brand new but unpolished C++ IDE
> that was hardly usable (believe me, I spent a lot of time trying to use
> it). That decision was of course internal to IBM and I cannot expect IBM
> to follow my advice (at least as long as I don't work for them), but maybe
> it could hear the advice of somebody else (e.g., the board/community/you).
> That other person could tell IBM - "It's really nice that you want to
> start another project, but do you mind helping us with project XXXX
> first?". Having *too many* unsuccessful projects (and I don't say there
> are too many of them now, I just say there are too many projects in
> general) doesn't make any good to the Eclipse project as a whole. That
> brings me to the second issue.
>
> The second issue is - does the eclipse project have a strategy, and what
> that strategy is? Being a JCP member I follow
> the JCP process and the JSRs that go through it. It looks like Sun governs
> the JCP process (with a right to veto decisions and only few other members
> in the executive committees)
> to fit into its strategic goals (as manufacturer of hardware, software,
> provider of services or whatever these goals are). I disagree with that
> goal as I see it, but at least it's strategy, and it is clear for me, for
> example, why Sun invests in J2EE (it helps selling pricey tools and
> servers) and invests much less in Java on the desktop (Sun does not make
> Windows or PCs). The difference between Swing and SWT tells it all.
> From what you describe any company that joins the eclipse board can start
> a new project to support their favorite product (few companies are truly
> philanthropic).
> Suppose I pay the membership fee, does that mean I can develop the new OS
> for my teapot as Eclipse project?
> I may be totally wrong about it, mainly because I didn't follow the
> formation of the consortium/board/etc. I'll be glad if you
> provide some pointers to relevant information.
>
> The statement that the people who work on the projects are the ones who
> want to work on it is only 90% true. That is, it is true for committers,
> but contributions from the broad audience must be first accepted by the
> project committers (who are usually employees of commercial companies, but
> that is irrelevant in this discussion) and I'm not sure what are the
> criteria of whether such contributions are reviewed and finally committed.
> For example, in early 2004 I had a (quite unpleasant) experience when I
> tried to contribute the autoboxing compiler code for the JDK1.5 effort (my
> largest attempt so far). I have spent more than a month of net work,
> studying the compiler internals, writing and testing the code (of course
> coordinated with the relevant committer). Eventually, the contribution was
> not accepted. Some reasons are clear and understandable, while some others
> are not.
>
> Genady
|
|
|
| Re: Eclipse Themes and Priorities [message #13596 is a reply to message #8661] |
Tue, 25 January 2005 03:35 |
Stephen Black
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Mike Milinkovich wrote:
> The Eclipse Development Process establishes the Requirements Council and
> gives that group the responsibility for establishing "themes and priorities"
> for development planning across the many Eclipse projects. The group's final
> draft can be found at
> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>
> Please note that the main purpose of the document is to establish a common
> set of themes and priorities for use across the many projects at Eclipse. It
> is hoped that individual projects will use a subset of these T&P's so that
> we have some consistency across the community. But individual projects also
> have the freedom to add their own if they feel that their needs are not met.
>
> As always, comments are appreciated.
>
> /mike
>
> Mike Milinkovich
> Executive Director
> Eclipse Foundation
>
>
>
>
I have only recently begun to use Eclipse. I sampled but dropped it
twice before (versions 1.x and 2.0). As of 3.1 I have confidence that
my concept of a universal development platform will actually be
achieved. There is one notable (to me) area that needs significant
improvement right now and that is text editing. My thoughts on this
seem to pertain to themes 3 and 7, so I will submit some comments here.
This is my first post to the newsgroups, so hopefully this won't be
found out of place.
I am a longtime CodeWright user. (It was the best choice after Borland
killed my Brief. Now they've killed CW too. Don't give those guys too
much power on the board, *please*!) I have tested the SlickEdit Plug-in
with Eclipse and found that it gave me what I was used to, but it also
robbed me of some important features of the JDT Java Editor. After
mulling over the dilemma for a while, I've decided that the best answer
would be to restructure the existing Eclipse editors as a hierarchy,
building function upon function. (I suspect that this is already the
case to some extent, so forgive me wherever I advocate what is already so.)
The JDT offers language specific functionality at both the syntax level
(e.g. coloring) and at the semantic level (e.g. dynamic error checking).
The semantic functionality is highly language dependent, but the
syntactical functionality is less so. CW and SE have long had a
standard lexer that is configurable for any language. This provides the
support for syntax coloring, code folding, etc. It allows me to work in
any language, even supplying my own set of keywords, comment delimiters,
etc. to define a hitherto unknown language.
I would like to see the Eclipse editors built hierarchically such that
code editors derived from (a) language editor(s) which derive from the
text editor -- with more or fewer levels as needed. Semantic
functionality could be added at the code-editor level to create a Java
editor, C++ editor, etc. Syntax functionality would be added at the
language-editor level to support coloring, etc. And the text editor
would supply all of the common capabilities for editing text. Ideally,
features added at one level (i.e. language) could be extended at a
higher level (i.e. code) for greater agility with the specific language.
(NOTE: I am using the term "language" in the generic sense of
identifiable part-of-speech tokens and the term "code" in the sense of
specific programming languages.) This architecture would allow greater
consistency of high-level features among the various code-specific editors.
Of course, there are other, possibly superior approaches to the same
end. For example, syntax- and semantic-processing plugins could be
created which could be attached to any text editor. The object should
be to provide the greatest possible consistency among code editors.
Eclipse should not be a Java IDE to Java developers and a C++ IDE to C++
developers, it should be a universal IDE to developers in one or more
languages. As much as possible, an editing feature available in one
language should be available and identical in all languages.
While I'm on the topic let me quickly lobby for a specific editor
enhancement. I like to color my comments with a background color to
make a strong dilineation between code blocks. I need an option to
specify the background color and another to specify that coloring should
extend to the right window edge (to avoid ragged edges).
There. That should be long-winded enough. If there is a more
appropriate place to post this information, please direct me there.
Thanks for the opportunity to feed back.
Steve
|
|
|
| Re: Eclipse Themes and Priorities [message #13636 is a reply to message #13596] |
Tue, 25 January 2005 06:39 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Steve,
I appreciate your feedback. Unfortunately the level of detail is probably a
little too deep for "Themes and Priorities". I think that eclipse.tools.jdt
may be a better newsgroup for the topic.
"Stephen C. Black" <StephenBlack@pobox.com> wrote in message
news:ct4epp$22n$1@www.eclipse.org...
> Mike Milinkovich wrote:
>> The Eclipse Development Process establishes the Requirements Council and
>> gives that group the responsibility for establishing "themes and
>> priorities" for development planning across the many Eclipse projects.
>> The group's final draft can be found at
>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>
>> Please note that the main purpose of the document is to establish a
>> common set of themes and priorities for use across the many projects at
>> Eclipse. It is hoped that individual projects will use a subset of these
>> T&P's so that we have some consistency across the community. But
>> individual projects also have the freedom to add their own if they feel
>> that their needs are not met.
>>
>> As always, comments are appreciated.
>>
>> /mike
>>
>> Mike Milinkovich
>> Executive Director
>> Eclipse Foundation
>>
>>
>>
>>
> I have only recently begun to use Eclipse. I sampled but dropped it twice
> before (versions 1.x and 2.0). As of 3.1 I have confidence that my
> concept of a universal development platform will actually be achieved.
> There is one notable (to me) area that needs significant improvement right
> now and that is text editing. My thoughts on this seem to pertain to
> themes 3 and 7, so I will submit some comments here. This is my first post
> to the newsgroups, so hopefully this won't be found out of place.
>
> I am a longtime CodeWright user. (It was the best choice after Borland
> killed my Brief. Now they've killed CW too. Don't give those guys too
> much power on the board, *please*!) I have tested the SlickEdit Plug-in
> with Eclipse and found that it gave me what I was used to, but it also
> robbed me of some important features of the JDT Java Editor. After
> mulling over the dilemma for a while, I've decided that the best answer
> would be to restructure the existing Eclipse editors as a hierarchy,
> building function upon function. (I suspect that this is already the case
> to some extent, so forgive me wherever I advocate what is already so.)
>
> The JDT offers language specific functionality at both the syntax level
> (e.g. coloring) and at the semantic level (e.g. dynamic error checking).
> The semantic functionality is highly language dependent, but the
> syntactical functionality is less so. CW and SE have long had a standard
> lexer that is configurable for any language. This provides the support
> for syntax coloring, code folding, etc. It allows me to work in any
> language, even supplying my own set of keywords, comment delimiters, etc.
> to define a hitherto unknown language.
>
> I would like to see the Eclipse editors built hierarchically such that
> code editors derived from (a) language editor(s) which derive from the
> text editor -- with more or fewer levels as needed. Semantic
> functionality could be added at the code-editor level to create a Java
> editor, C++ editor, etc. Syntax functionality would be added at the
> language-editor level to support coloring, etc. And the text editor would
> supply all of the common capabilities for editing text. Ideally, features
> added at one level (i.e. language) could be extended at a higher level
> (i.e. code) for greater agility with the specific language. (NOTE: I am
> using the term "language" in the generic sense of identifiable
> part-of-speech tokens and the term "code" in the sense of specific
> programming languages.) This architecture would allow greater consistency
> of high-level features among the various code-specific editors.
>
> Of course, there are other, possibly superior approaches to the same end.
> For example, syntax- and semantic-processing plugins could be created
> which could be attached to any text editor. The object should be to
> provide the greatest possible consistency among code editors. Eclipse
> should not be a Java IDE to Java developers and a C++ IDE to C++
> developers, it should be a universal IDE to developers in one or more
> languages. As much as possible, an editing feature available in one
> language should be available and identical in all languages.
>
> While I'm on the topic let me quickly lobby for a specific editor
> enhancement. I like to color my comments with a background color to make
> a strong dilineation between code blocks. I need an option to specify the
> background color and another to specify that coloring should extend to the
> right window edge (to avoid ragged edges).
>
> There. That should be long-winded enough. If there is a more appropriate
> place to post this information, please direct me there.
>
> Thanks for the opportunity to feed back.
>
> Steve
|
|
|
| Re: Eclipse Themes and Priorities [message #13696 is a reply to message #13636] |
Tue, 25 January 2005 11:51 |
| Eclipse User |
|
|
|
Originally posted by: daniel.megert.gmx.net
Mike Milinkovich wrote:
>Steve,
>
>I appreciate your feedback. Unfortunately the level of detail is probably a
>little too deep for "Themes and Priorities". I think that eclipse.tools.jdt
>may be a better newsgroup for the topic.
>
>
And take a look at the open feature request in bugzilla and add your
comments there as well, e.g. for the background color there's already one.
HTH
Dani
>"Stephen C. Black" <StephenBlack@pobox.com> wrote in message
>news:ct4epp$22n$1@www.eclipse.org...
>
>
>>Mike Milinkovich wrote:
>>
>>
>>>The Eclipse Development Process establishes the Requirements Council and
>>>gives that group the responsibility for establishing "themes and
>>>priorities" for development planning across the many Eclipse projects.
>>>The group's final draft can be found at
>>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>>
>>>Please note that the main purpose of the document is to establish a
>>>common set of themes and priorities for use across the many projects at
>>>Eclipse. It is hoped that individual projects will use a subset of these
>>>T&P's so that we have some consistency across the community. But
>>>individual projects also have the freedom to add their own if they feel
>>>that their needs are not met.
>>>
>>>As always, comments are appreciated.
>>>
>>>/mike
>>>
>>>Mike Milinkovich
>>>Executive Director
>>>Eclipse Foundation
>>>
>>>
>>>
>>>
>>>
>>>
>>I have only recently begun to use Eclipse. I sampled but dropped it twice
>>before (versions 1.x and 2.0). As of 3.1 I have confidence that my
>>concept of a universal development platform will actually be achieved.
>>There is one notable (to me) area that needs significant improvement right
>>now and that is text editing. My thoughts on this seem to pertain to
>>themes 3 and 7, so I will submit some comments here. This is my first post
>>to the newsgroups, so hopefully this won't be found out of place.
>>
>>I am a longtime CodeWright user. (It was the best choice after Borland
>>killed my Brief. Now they've killed CW too. Don't give those guys too
>>much power on the board, *please*!) I have tested the SlickEdit Plug-in
>>with Eclipse and found that it gave me what I was used to, but it also
>>robbed me of some important features of the JDT Java Editor. After
>>mulling over the dilemma for a while, I've decided that the best answer
>>would be to restructure the existing Eclipse editors as a hierarchy,
>>building function upon function. (I suspect that this is already the case
>>to some extent, so forgive me wherever I advocate what is already so.)
>>
>>The JDT offers language specific functionality at both the syntax level
>>(e.g. coloring) and at the semantic level (e.g. dynamic error checking).
>>The semantic functionality is highly language dependent, but the
>>syntactical functionality is less so. CW and SE have long had a standard
>>lexer that is configurable for any language. This provides the support
>>for syntax coloring, code folding, etc. It allows me to work in any
>>language, even supplying my own set of keywords, comment delimiters, etc.
>>to define a hitherto unknown language.
>>
>>I would like to see the Eclipse editors built hierarchically such that
>>code editors derived from (a) language editor(s) which derive from the
>>text editor -- with more or fewer levels as needed. Semantic
>>functionality could be added at the code-editor level to create a Java
>>editor, C++ editor, etc. Syntax functionality would be added at the
>>language-editor level to support coloring, etc. And the text editor would
>>supply all of the common capabilities for editing text. Ideally, features
>>added at one level (i.e. language) could be extended at a higher level
>>(i.e. code) for greater agility with the specific language. (NOTE: I am
>>using the term "language" in the generic sense of identifiable
>>part-of-speech tokens and the term "code" in the sense of specific
>>programming languages.) This architecture would allow greater consistency
>>of high-level features among the various code-specific editors.
>>
>>Of course, there are other, possibly superior approaches to the same end.
>>For example, syntax- and semantic-processing plugins could be created
>>which could be attached to any text editor. The object should be to
>>provide the greatest possible consistency among code editors. Eclipse
>>should not be a Java IDE to Java developers and a C++ IDE to C++
>>developers, it should be a universal IDE to developers in one or more
>>languages. As much as possible, an editing feature available in one
>>language should be available and identical in all languages.
>>
>>While I'm on the topic let me quickly lobby for a specific editor
>>enhancement. I like to color my comments with a background color to make
>>a strong dilineation between code blocks. I need an option to specify the
>>background color and another to specify that coloring should extend to the
>>right window edge (to avoid ragged edges).
>>
>>There. That should be long-winded enough. If there is a more appropriate
>>place to post this information, please direct me there.
>>
>>Thanks for the opportunity to feed back.
>>
>>Steve
>>
>>
>
>
>
>
|
|
|
| Re: Eclipse Themes and Priorities [message #13760 is a reply to message #13636] |
Tue, 25 January 2005 18:04 |
| Eclipse User |
|
|
|
Originally posted by: gwatson.lanl.gov
I think Steve raises an important theme, which is that the current
Eclipse design has resulted in distinct islands of language support that
force the re-implementation of the same features for each new language.
Even providing support for a language like Fortran, which is
syntactically quite close to C, requires duplication of much of the CDT
functionality. I would strongly support an approach that separates the
language-independent functionality from the language-dependent
functionality and provides a set of language-independent services that
would be available for any language implementation to utilize.
Greg
Mike Milinkovich wrote:
> Steve,
>
> I appreciate your feedback. Unfortunately the level of detail is probably a
> little too deep for "Themes and Priorities". I think that eclipse.tools.jdt
> may be a better newsgroup for the topic.
>
> "Stephen C. Black" <StephenBlack@pobox.com> wrote in message
> news:ct4epp$22n$1@www.eclipse.org...
>
>>Mike Milinkovich wrote:
>>
>>>The Eclipse Development Process establishes the Requirements Council and
>>>gives that group the responsibility for establishing "themes and
>>>priorities" for development planning across the many Eclipse projects.
>>>The group's final draft can be found at
>>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>>
>>>Please note that the main purpose of the document is to establish a
>>>common set of themes and priorities for use across the many projects at
>>>Eclipse. It is hoped that individual projects will use a subset of these
>>>T&P's so that we have some consistency across the community. But
>>>individual projects also have the freedom to add their own if they feel
>>>that their needs are not met.
>>>
>>>As always, comments are appreciated.
>>>
>>>/mike
>>>
>>>Mike Milinkovich
>>>Executive Director
>>>Eclipse Foundation
>>>
>>>
>>>
>>>
>>
>>I have only recently begun to use Eclipse. I sampled but dropped it twice
>>before (versions 1.x and 2.0). As of 3.1 I have confidence that my
>>concept of a universal development platform will actually be achieved.
>>There is one notable (to me) area that needs significant improvement right
>>now and that is text editing. My thoughts on this seem to pertain to
>>themes 3 and 7, so I will submit some comments here. This is my first post
>>to the newsgroups, so hopefully this won't be found out of place.
>>
>>I am a longtime CodeWright user. (It was the best choice after Borland
>>killed my Brief. Now they've killed CW too. Don't give those guys too
>>much power on the board, *please*!) I have tested the SlickEdit Plug-in
>>with Eclipse and found that it gave me what I was used to, but it also
>>robbed me of some important features of the JDT Java Editor. After
>>mulling over the dilemma for a while, I've decided that the best answer
>>would be to restructure the existing Eclipse editors as a hierarchy,
>>building function upon function. (I suspect that this is already the case
>>to some extent, so forgive me wherever I advocate what is already so.)
>>
>>The JDT offers language specific functionality at both the syntax level
>>(e.g. coloring) and at the semantic level (e.g. dynamic error checking).
>>The semantic functionality is highly language dependent, but the
>>syntactical functionality is less so. CW and SE have long had a standard
>>lexer that is configurable for any language. This provides the support
>>for syntax coloring, code folding, etc. It allows me to work in any
>>language, even supplying my own set of keywords, comment delimiters, etc.
>>to define a hitherto unknown language.
>>
>>I would like to see the Eclipse editors built hierarchically such that
>>code editors derived from (a) language editor(s) which derive from the
>>text editor -- with more or fewer levels as needed. Semantic
>>functionality could be added at the code-editor level to create a Java
>>editor, C++ editor, etc. Syntax functionality would be added at the
>>language-editor level to support coloring, etc. And the text editor would
>>supply all of the common capabilities for editing text. Ideally, features
>>added at one level (i.e. language) could be extended at a higher level
>>(i.e. code) for greater agility with the specific language. (NOTE: I am
>>using the term "language" in the generic sense of identifiable
>>part-of-speech tokens and the term "code" in the sense of specific
>>programming languages.) This architecture would allow greater consistency
>>of high-level features among the various code-specific editors.
>>
>>Of course, there are other, possibly superior approaches to the same end.
>>For example, syntax- and semantic-processing plugins could be created
>>which could be attached to any text editor. The object should be to
>>provide the greatest possible consistency among code editors. Eclipse
>>should not be a Java IDE to Java developers and a C++ IDE to C++
>>developers, it should be a universal IDE to developers in one or more
>>languages. As much as possible, an editing feature available in one
>>language should be available and identical in all languages.
>>
>>While I'm on the topic let me quickly lobby for a specific editor
>>enhancement. I like to color my comments with a background color to make
>>a strong dilineation between code blocks. I need an option to specify the
>>background color and another to specify that coloring should extend to the
>>right window edge (to avoid ragged edges).
>>
>>There. That should be long-winded enough. If there is a more appropriate
>>place to post this information, please direct me there.
>>
>>Thanks for the opportunity to feed back.
>>
>>Steve
>
>
>
|
|
|
| Re: Eclipse Themes and Priorities [message #13799 is a reply to message #13246] |
Tue, 25 January 2005 20:51 |
Genady Beryozkin
Messages: 410
Registered: July 2009 |
Senior Member |
|
|
Thanks for the pointers. I will look into it.
Genady
Mike Milinkovich wrote:
>Genay,
>
>I started to write a very long answer to this, but I stopped. I was
>basically re-writing tons of information which is available on the website
>elsewhere.
>
>Here is a sampling of pages you may want to read.
>
>1. Eclipse Development Process at
> http://www.eclipse.org/org/documents/Eclipse%20Development%2 0Process%202003_11_09%20FINAL.pdf
>2. The Eclipse Councils at http://www.eclipse.org/org/council.html. Take a
>look at the Themes and Priorities document, and keep an eye out for the
>upcoming Planning and Architecture documents.
>3. You may be interested in just reading the "Purposes" section of our
>bylaws at
> http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003 _11_10%20Final.pdf
>
>I think that we are going to have to agree to disagree on the notion that
>there are too many projects. We are hoping to add more. Eclipse has *never*
>been about just the Java IDE. It has always been about building a
>development platform targeted at many problem domains. In the case of CDT, I
>am sorry that it did not meet your expectations, but in my mind the solution
>is to recruit more developers to add resources to it.
>
>Eclipse does have a strategy. Much of which is embodied in the documents
>above. More documentation is coming in the form of the Eclipse Roadmap
>document which is going to be completed by the end of Feb.
>
>I personally am uncomfortable with any comparison of Eclipse and the JCP.
>The JCP is a standard organization led by one vendor. Eclipse is an open
>source community led by a Foundation which has many members.
>
>As to accepting contributions, those decisions reside completely with the
>project and its committers. I don't know the history your attempt, but I can
>only assume that the responsible committers had valid reasons. That does not
>necessarily mean there was anything wrong with your contribution. There
>could be a myriad of reasons such as risk, backwards compatibility, or
>synergy with future directions why a contribution may not work out. But I
>believe that is true of every open source project, not just Eclipse.
>
>"Genady" <eclipse@genady.org> wrote in message
>news:csuevo$iit$1@www.eclipse.org...
>
>
>>Mike Milinkovich wrote:
>>
>>
>>
>>>I *suspect* (don't know for sure) that you may misunderstand how resources
>>>get allocated at Eclipse (and it most open source projects). If you think
>>>that the Foundation or its Executive Director allocates resources across
>>>the projects, you are mistaken. The people who work on the projects are
>>>the ones who *want* to work on it, or who have been asked to work on it by
>>>their employers (and hopefully they enjoy doing so!).
>>>
>>>
>>>
>>(It turned into something longer than I initially intended ...)
>>
>>There are two separate issues. If I don't mistake (please correct me if
>>I'm wrong) there are few companies that
>>"contribute" their employees to work on the various projects, with
>>probably IBM being the most dominant contributor.
>>I'm sorry to get back to the CDT project, but initially it was developed
>>by IBM employees, and at that point of time,
>>I can say with confidence, that I would rather see more useful features in
>>JDT rather than a brand new but unpolished C++ IDE
>>that was hardly usable (believe me, I spent a lot of time trying to use
>>it). That decision was of course internal to IBM and I cannot expect IBM
>>to follow my advice (at least as long as I don't work for them), but maybe
>>it could hear the advice of somebody else (e.g., the board/community/you).
>>That other person could tell IBM - "It's really nice that you want to
>>start another project, but do you mind helping us with project XXXX
>>first?". Having *too many* unsuccessful projects (and I don't say there
>>are too many of them now, I just say there are too many projects in
>>general) doesn't make any good to the Eclipse project as a whole. That
>>brings me to the second issue.
>>
>>The second issue is - does the eclipse project have a strategy, and what
>>that strategy is? Being a JCP member I follow
>>the JCP process and the JSRs that go through it. It looks like Sun governs
>>the JCP process (with a right to veto decisions and only few other members
>>in the executive committees)
>>to fit into its strategic goals (as manufacturer of hardware, software,
>>provider of services or whatever these goals are). I disagree with that
>>goal as I see it, but at least it's strategy, and it is clear for me, for
>>example, why Sun invests in J2EE (it helps selling pricey tools and
>>servers) and invests much less in Java on the desktop (Sun does not make
>>Windows or PCs). The difference between Swing and SWT tells it all.
>>From what you describe any company that joins the eclipse board can start
>>a new project to support their favorite product (few companies are truly
>>philanthropic).
>>Suppose I pay the membership fee, does that mean I can develop the new OS
>>for my teapot as Eclipse project?
>>I may be totally wrong about it, mainly because I didn't follow the
>>formation of the consortium/board/etc. I'll be glad if you
>>provide some pointers to relevant information.
>>
>>The statement that the people who work on the projects are the ones who
>>want to work on it is only 90% true. That is, it is true for committers,
>>but contributions from the broad audience must be first accepted by the
>>project committers (who are usually employees of commercial companies, but
>>that is irrelevant in this discussion) and I'm not sure what are the
>>criteria of whether such contributions are reviewed and finally committed.
>>For example, in early 2004 I had a (quite unpleasant) experience when I
>>tried to contribute the autoboxing compiler code for the JDK1.5 effort (my
>>largest attempt so far). I have spent more than a month of net work,
>>studying the compiler internals, writing and testing the code (of course
>>coordinated with the relevant committer). Eventually, the contribution was
>>not accepted. Some reasons are clear and understandable, while some others
>>are not.
>>
>>Genady
>>
>>
>
>
>
>
|
|
|
| Re: Eclipse Themes and Priorities [message #13945 is a reply to message #13760] |
Tue, 25 January 2005 21:32 |
| Eclipse User |
|
|
|
Originally posted by: Chris_Laffra.ca.ibm.com
Hi Greg,
+1 vote from me.
If you are coming to EclipseCON this year, please consider coming
to the BOF on language toolkits on Monday evening. Exact
time/location are still to be determined.
http://www.eclipse.org/newsportal/article.php?id=20&grou p=eclipse.eclipsecon
Furthermore, there is going to be a Tech Exchange on Wednesday
evening on the same topic (to present the results of Monday's BOF
and what some people have been doing in the area of language
toolkits and universal IDEs.)
See http://www.eclipsecon.org/calday.php?day=3
Some people have milled around the proposal of a "univeral IDE"
along the lines you mention. Let's meet at the BOF to see if
we can get enough momentum going for an eclipse project?
--
Chris Laffra, http://eclipsefaq.org
"Greg Watson" <gwatson@lanl.gov> wrote in message
news:ct61n9$mt8$1@www.eclipse.org...
> I think Steve raises an important theme, which is that the current
> Eclipse design has resulted in distinct islands of language support that
> force the re-implementation of the same features for each new language.
> Even providing support for a language like Fortran, which is
> syntactically quite close to C, requires duplication of much of the CDT
> functionality. I would strongly support an approach that separates the
> language-independent functionality from the language-dependent
> functionality and provides a set of language-independent services that
> would be available for any language implementation to utilize.
>
> Greg
>
> Mike Milinkovich wrote:
> > Steve,
> >
> > I appreciate your feedback. Unfortunately the level of detail is
probably a
> > little too deep for "Themes and Priorities". I think that
eclipse.tools.jdt
> > may be a better newsgroup for the topic.
> >
> > "Stephen C. Black" <StephenBlack@pobox.com> wrote in message
> > news:ct4epp$22n$1@www.eclipse.org...
> >
> >>Mike Milinkovich wrote:
> >>
> >>>The Eclipse Development Process establishes the Requirements Council
and
> >>>gives that group the responsibility for establishing "themes and
> >>>priorities" for development planning across the many Eclipse projects.
> >>>The group's final draft can be found at
> >>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
> >>>
> >>>Please note that the main purpose of the document is to establish a
> >>>common set of themes and priorities for use across the many projects at
> >>>Eclipse. It is hoped that individual projects will use a subset of
these
> >>>T&P's so that we have some consistency across the community. But
> >>>individual projects also have the freedom to add their own if they feel
> >>>that their needs are not met.
> >>>
> >>>As always, comments are appreciated.
> >>>
> >>>/mike
> >>>
> >>>Mike Milinkovich
> >>>Executive Director
> >>>Eclipse Foundation
> >>>
> >>>
> >>>
> >>>
> >>
> >>I have only recently begun to use Eclipse. I sampled but dropped it
twice
> >>before (versions 1.x and 2.0). As of 3.1 I have confidence that my
> >>concept of a universal development platform will actually be achieved.
> >>There is one notable (to me) area that needs significant improvement
right
> >>now and that is text editing. My thoughts on this seem to pertain to
> >>themes 3 and 7, so I will submit some comments here. This is my first
post
> >>to the newsgroups, so hopefully this won't be found out of place.
> >>
> >>I am a longtime CodeWright user. (It was the best choice after Borland
> >>killed my Brief. Now they've killed CW too. Don't give those guys too
> >>much power on the board, *please*!) I have tested the SlickEdit Plug-in
> >>with Eclipse and found that it gave me what I was used to, but it also
> >>robbed me of some important features of the JDT Java Editor. After
> >>mulling over the dilemma for a while, I've decided that the best answer
> >>would be to restructure the existing Eclipse editors as a hierarchy,
> >>building function upon function. (I suspect that this is already the
case
> >>to some extent, so forgive me wherever I advocate what is already so.)
> >>
> >>The JDT offers language specific functionality at both the syntax level
> >>(e.g. coloring) and at the semantic level (e.g. dynamic error checking).
> >>The semantic functionality is highly language dependent, but the
> >>syntactical functionality is less so. CW and SE have long had a
standard
> >>lexer that is configurable for any language. This provides the support
> >>for syntax coloring, code folding, etc. It allows me to work in any
> >>language, even supplying my own set of keywords, comment delimiters,
etc.
> >>to define a hitherto unknown language.
> >>
> >>I would like to see the Eclipse editors built hierarchically such that
> >>code editors derived from (a) language editor(s) which derive from the
> >>text editor -- with more or fewer levels as needed. Semantic
> >>functionality could be added at the code-editor level to create a Java
> >>editor, C++ editor, etc. Syntax functionality would be added at the
> >>language-editor level to support coloring, etc. And the text editor
would
> >>supply all of the common capabilities for editing text. Ideally,
features
> >>added at one level (i.e. language) could be extended at a higher level
> >>(i.e. code) for greater agility with the specific language. (NOTE: I am
> >>using the term "language" in the generic sense of identifiable
> >>part-of-speech tokens and the term "code" in the sense of specific
> >>programming languages.) This architecture would allow greater
consistency
> >>of high-level features among the various code-specific editors.
> >>
> >>Of course, there are other, possibly superior approaches to the same
end.
> >>For example, syntax- and semantic-processing plugins could be created
> >>which could be attached to any text editor. The object should be to
> >>provide the greatest possible consistency among code editors. Eclipse
> >>should not be a Java IDE to Java developers and a C++ IDE to C++
> >>developers, it should be a universal IDE to developers in one or more
> >>languages. As much as possible, an editing feature available in one
> >>language should be available and identical in all languages.
> >>
> >>While I'm on the topic let me quickly lobby for a specific editor
> >>enhancement. I like to color my comments with a background color to
make
> >>a strong dilineation between code blocks. I need an option to specify
the
> >>background color and another to specify that coloring should extend to
the
> >>right window edge (to avoid ragged edges).
> >>
> >>There. That should be long-winded enough. If there is a more
appropriate
> >>place to post this information, please direct me there.
> >>
> >>Thanks for the opportunity to feed back.
> >>
> >>Steve
> >
> >
> >
|
|
|
| Re: Eclipse Themes and Priorities [message #13946 is a reply to message #13945] |
Tue, 25 January 2005 22:08 |
| Eclipse User |
|
|
|
Originally posted by: gwatson.lanl.gov
Hi Chris,
Sounds great. I'll try to get to both, but in the event of time clashes
(we're trying to set up a BOF too), one of my developers will definitely
get there.
Looking forward to discussing this in more detail,
Greg
Chris Laffra wrote:
> Hi Greg,
>
> +1 vote from me.
>
> If you are coming to EclipseCON this year, please consider coming
> to the BOF on language toolkits on Monday evening. Exact
> time/location are still to be determined.
> http://www.eclipse.org/newsportal/article.php?id=20&grou p=eclipse.eclipsecon
>
> Furthermore, there is going to be a Tech Exchange on Wednesday
> evening on the same topic (to present the results of Monday's BOF
> and what some people have been doing in the area of language
> toolkits and universal IDEs.)
> See http://www.eclipsecon.org/calday.php?day=3
>
> Some people have milled around the proposal of a "univeral IDE"
> along the lines you mention. Let's meet at the BOF to see if
> we can get enough momentum going for an eclipse project?
>
|
|
|
| Re: Eclipse Themes and Priorities [message #13949 is a reply to message #13636] |
Wed, 26 January 2005 00:30 |
Stephen Black
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Mike Milinkovich wrote:
> Steve,
>
> I appreciate your feedback. Unfortunately the level of detail is probably a
> little too deep for "Themes and Priorities". I think that eclipse.tools.jdt
> may be a better newsgroup for the topic.
>
> "Stephen C. Black" <StephenBlack@pobox.com> wrote in message
> news:ct4epp$22n$1@www.eclipse.org...
>
>>Mike Milinkovich wrote:
>>
>>>The Eclipse Development Process establishes the Requirements Council and
>>>gives that group the responsibility for establishing "themes and
>>>priorities" for development planning across the many Eclipse projects.
>>>The group's final draft can be found at
>>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>>
>>>Please note that the main purpose of the document is to establish a
>>>common set of themes and priorities for use across the many projects at
>>>Eclipse. It is hoped that individual projects will use a subset of these
>>>T&P's so that we have some consistency across the community. But
>>>individual projects also have the freedom to add their own if they feel
>>>that their needs are not met.
>>>
>>>As always, comments are appreciated.
>>>
>>>/mike
>>>
>>>Mike Milinkovich
>>>Executive Director
>>>Eclipse Foundation
>>>
>>>
>>>
>>>
>>
>>I have only recently begun to use Eclipse. I sampled but dropped it twice
>>before (versions 1.x and 2.0). As of 3.1 I have confidence that my
>>concept of a universal development platform will actually be achieved.
>>There is one notable (to me) area that needs significant improvement right
>>now and that is text editing. My thoughts on this seem to pertain to
>>themes 3 and 7, so I will submit some comments here. This is my first post
>>to the newsgroups, so hopefully this won't be found out of place.
>>
>>I am a longtime CodeWright user. (It was the best choice after Borland
>>killed my Brief. Now they've killed CW too. Don't give those guys too
>>much power on the board, *please*!) I have tested the SlickEdit Plug-in
>>with Eclipse and found that it gave me what I was used to, but it also
>>robbed me of some important features of the JDT Java Editor. After
>>mulling over the dilemma for a while, I've decided that the best answer
>>would be to restructure the existing Eclipse editors as a hierarchy,
>>building function upon function. (I suspect that this is already the case
>>to some extent, so forgive me wherever I advocate what is already so.)
>>
>>The JDT offers language specific functionality at both the syntax level
>>(e.g. coloring) and at the semantic level (e.g. dynamic error checking).
>>The semantic functionality is highly language dependent, but the
>>syntactical functionality is less so. CW and SE have long had a standard
>>lexer that is configurable for any language. This provides the support
>>for syntax coloring, code folding, etc. It allows me to work in any
>>language, even supplying my own set of keywords, comment delimiters, etc.
>>to define a hitherto unknown language.
>>
>>I would like to see the Eclipse editors built hierarchically such that
>>code editors derived from (a) language editor(s) which derive from the
>>text editor -- with more or fewer levels as needed. Semantic
>>functionality could be added at the code-editor level to create a Java
>>editor, C++ editor, etc. Syntax functionality would be added at the
>>language-editor level to support coloring, etc. And the text editor would
>>supply all of the common capabilities for editing text. Ideally, features
>>added at one level (i.e. language) could be extended at a higher level
>>(i.e. code) for greater agility with the specific language. (NOTE: I am
>>using the term "language" in the generic sense of identifiable
>>part-of-speech tokens and the term "code" in the sense of specific
>>programming languages.) This architecture would allow greater consistency
>>of high-level features among the various code-specific editors.
>>
>>Of course, there are other, possibly superior approaches to the same end.
>>For example, syntax- and semantic-processing plugins could be created
>>which could be attached to any text editor. The object should be to
>>provide the greatest possible consistency among code editors. Eclipse
>>should not be a Java IDE to Java developers and a C++ IDE to C++
>>developers, it should be a universal IDE to developers in one or more
>>languages. As much as possible, an editing feature available in one
>>language should be available and identical in all languages.
>>
>>While I'm on the topic let me quickly lobby for a specific editor
>>enhancement. I like to color my comments with a background color to make
>>a strong dilineation between code blocks. I need an option to specify the
>>background color and another to specify that coloring should extend to the
>>right window edge (to avoid ragged edges).
>>
>>There. That should be long-winded enough. If there is a more appropriate
>>place to post this information, please direct me there.
>>
>>Thanks for the opportunity to feed back.
>>
>>Steve
>
>
>
Thanks, Mike. I'll do that. Whatever else, it will help me learn my
way around the premises.
|
|
|
| Re: Eclipse Themes and Priorities [message #13950 is a reply to message #13696] |
Wed, 26 January 2005 00:31 |
Stephen Black
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Daniel Megert wrote:
> Mike Milinkovich wrote:
>
>> Steve,
>>
>> I appreciate your feedback. Unfortunately the level of detail is
>> probably a little too deep for "Themes and Priorities". I think that
>> eclipse.tools.jdt may be a better newsgroup for the topic.
>>
>>
> And take a look at the open feature request in bugzilla and add your
> comments there as well, e.g. for the background color there's already one.
>
> HTH
> Dani
>
>> "Stephen C. Black" <StephenBlack@pobox.com> wrote in message
>> news:ct4epp$22n$1@www.eclipse.org...
>>
>>
>>> Mike Milinkovich wrote:
>>>
>>>
>>>> The Eclipse Development Process establishes the Requirements Council
>>>> and gives that group the responsibility for establishing "themes and
>>>> priorities" for development planning across the many Eclipse
>>>> projects. The group's final draft can be found at
>>>> http://www.eclipse.org/org/councils/20041215EclipseTPFinalDr aft.pdf.
>>>>
>>>> Please note that the main purpose of the document is to establish a
>>>> common set of themes and priorities for use across the many projects
>>>> at Eclipse. It is hoped that individual projects will use a subset
>>>> of these T&P's so that we have some consistency across the
>>>> community. But individual projects also have the freedom to add
>>>> their own if they feel that their needs are not met.
>>>>
>>>> As always, comments are appreciated.
>>>>
>>>> /mike
>>>>
>>>> Mike Milinkovich
>>>> Executive Director
>>>> Eclipse Foundation
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> I have only recently begun to use Eclipse. I sampled but dropped it
>>> twice before (versions 1.x and 2.0). As of 3.1 I have confidence
>>> that my concept of a universal development platform will actually be
>>> achieved. There is one notable (to me) area that needs significant
>>> improvement right now and that is text editing. My thoughts on this
>>> seem to pertain to themes 3 and 7, so I will submit some comments
>>> here. This is my first post to the newsgroups, so hopefully this
>>> won't be found out of place.
>>>
>>> I am a longtime CodeWright user. (It was the best choice after
>>> Borland killed my Brief. Now they've killed CW too. Don't give
>>> those guys too much power on the board, *please*!) I have tested the
>>> SlickEdit Plug-in with Eclipse and found that it gave me what I was
>>> used to, but it also robbed me of some important features of the JDT
>>> Java Editor. After mulling over the dilemma for a while, I've
>>> decided that the best answer would be to restructure the existing
>>> Eclipse editors as a hierarchy, building function upon function. (I
>>> suspect that this is already the case to some extent, so forgive me
>>> wherever I advocate what is already so.)
>>>
>>> The JDT offers language specific functionality at both the syntax
>>> level (e.g. coloring) and at the semantic level (e.g. dynamic error
>>> checking). The semantic functionality is highly language dependent,
>>> but the syntactical functionality is less so. CW and SE have long
>>> had a standard lexer that is configurable for any language. This
>>> provides the support for syntax coloring, code folding, etc. It
>>> allows me to work in any language, even supplying my own set of
>>> keywords, comment delimiters, etc. to define a hitherto unknown
>>> language.
>>>
>>> I would like to see the Eclipse editors built hierarchically such
>>> that code editors derived from (a) language editor(s) which derive
>>> from the text editor -- with more or fewer levels as needed.
>>> Semantic functionality could be added at the code-editor level to
>>> create a Java editor, C++ editor, etc. Syntax functionality would be
>>> added at the language-editor level to support coloring, etc. And the
>>> text editor would supply all of the common capabilities for editing
>>> text. Ideally, features added at one level (i.e. language) could be
>>> extended at a higher level (i.e. code) for greater agility with the
>>> specific language. (NOTE: I am using the term "language" in the
>>> generic sense of identifiable part-of-speech tokens and the term
>>> "code" in the sense of specific programming languages.) This
>>> architecture would allow greater consistency of high-level features
>>> among the various code-specific editors.
>>>
>>> Of course, there are other, possibly superior approaches to the same
>>> end. For example, syntax- and semantic-processing plugins could be
>>> created which could be attached to any text editor. The object
>>> should be to provide the greatest possible consistency among code
>>> editors. Eclipse should not be a Java IDE to Java developers and a
>>> C++ IDE to C++ developers, it should be a universal IDE to developers
>>> in one or more languages. As much as possible, an editing feature
>>> available in one language should be available and identical in all
>>> languages.
>>>
>>> While I'm on the topic let me quickly lobby for a specific editor
>>> enhancement. I like to color my comments with a background color to
>>> make a strong dilineation between code blocks. I need an option to
>>> specify the background color and another to specify that coloring
>>> should extend to the right window edge (to avoid ragged edges).
>>>
>>> There. That should be long-winded enough. If there is a more
>>> appropriate place to post this information, please direct me there.
>>>
>>> Thanks for the opportunity to feed back.
>>>
>>> Steve
>>
>>
>>
>>
>>
Good idea, Dani. I'll try that too.
|
|
| | | |
| Re: Eclipse Themes and Priorities [message #14359 is a reply to message #12931] |
Fri, 28 January 2005 15:53 |
| Eclipse User |
|
|
|
Originally posted by: myname(with.between names).lombardisoftware.com
Only GTK support is actually a pretty frustrating issue (IMHO).
Just supporting GTK is supporting only half the Linux community. I know
Gnome might be bigger in the US, but in the rest of the world that isn't
the case (if not reversed). Eclipse does not work that well with KDE (not
that it doesn't work, but it doesn't work well IMSNHO).
According to:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=20486
There is no issue (according to people who knows more than me) with _QPL_
(Qt is not just licensed under GPL) which the free version of QT/Linux is
licensed under. But since someone decided it was at some point, there is no
way anyone can prove this without hiring their own lawyer I guess.
Genady wrote:
>
> Mike Milinkovich wrote:
>
>>Genady,
>>
>>Thanks for the comments.
>>
>>Regarding the number of projects at Eclipse, that's a really good
>>question. It certainly doesn't hurt every once in a while to go back to
>>first principles.
>>
>>First, Eclipse has always been about more languages and platforms than
>>Java alone. That was one of the reasons why Eclipse built SWT rather than
>>going with Swing. There have been multiple projects at Eclipse almost from
>>the first day.
>>So the goal of Eclipse is to be a development platform --- not just a Java
>>IDE. Although we are best known for it, Eclipse is not a Java IDE. It is
>>an open source community.
>>
>>I personally don't mind if occasionally a project fails. If you don't fail
>>once in a while, you're not trying.
>>
>>
>>
> As long as the live/dead ratio is good and this is also result from
> resource allocation.
> I think that the great success of JDT is partially due to the support it
> got from IBM. I'm sure not all projects
> can receive such attention (either from IBM or other companies), so I
> hope and believe resources are allocated thoughtfully.
>
> I also feel that because there are so many projects I cannot check them
> all to really understand what they are about or whether they are mature
> enough to be used in commercial environment (My employer cannot let me
> contribute code, but I try to do that privately).
> Maybe there should be the "front line" of mature projects (such as
> Platform/RCP, JDT, CDT) and what IBM called
> "alphaworks". Part of that confusion leads to the problems with the
> download page layout (see other thread in this group) -
> "How can you tell the users what they should download".
>
>>As for the specific example you raised, I think you're dead wrong about
>>CDT's success and its potential for the future. CDT is being used by many
>>RTOS vendors as their IDE. It is shipping with the RedHat and Suse Linux
>>distro's. And there are lots of great things coming down the pipe for it.
>>I actually think it has been a big success.
>>
>>
>>
> I have been following CDT project since its creation and checked in once
> in a while. I've last checked CDT few months ago and I will definitely
> look at it again. I believe it cannot compete with VisualStudio on the
> Windows platform and on Unix, it suffers from various look and feel
> problems (discussed elsewhere).
>
> Maybe there should be an effort to develop a new SWT implementation
> based on toolkits other than GTK (e.g., qt). I know there are license
> incompatibilities but can you tell me what's wrong with the following
> scenario:
> * Eclipse ships as usual on all platforms with current SWT implementations
> * An independent group of developers develops qt-based implementation
> and publishes it under the appropriate license
> * Users download the qt implementation of SWT, install it on their
> machine and Eclipse will pick it up.
>
> This is similar to GPL applications for Windows - Using such
> applications does not force Windows to be licensed under GPL.
>
> Genady
>
>>
>>
|
|
|
Goto Forum:
Current Time: Sat Nov 09 02:08:43 GMT 2024
Powered by FUDForum. Page generated in 0.07435 seconds |
] 
Search
Help
Register
Login
Home
