Re: Strange WOLips importing error
Re: Strange WOLips importing error
- Subject: Re: Strange WOLips importing error
- From: Mike Schrag <email@hidden>
- Date: Sun, 25 Nov 2007 13:04:31 -0500
I disagree... Eclipse is not just against Xcode philosophy. Eclipse
contradicts any Apple HIG and any sane usability guidelines,
While I completely agree that Eclipse has plenty of problems, my main
point was that every IDE has UI problems -- they are very complicated
tools. You've just become accustomed to accepting Xcode's problems
and you're put off by Eclipse's different set of problems (whereas I'm
totally put off by Xcode's confusing user interfaces for Java
development and its comparative lack of features). Look at any of
Apple's pro tools (Final Cut Pro comes to mind). They all have custom
user interfaces and they're all much more complicated than, say,
iPhoto, because the people who use pro tools have much higher demands
on customization and productivity. For the most part, I have yet to
see a pro tool that is really able to deliver the ease-of-use of an
Apple consumer app without sacrificing functionality. Interface
Builder is one, and I think Xray (err . whatever it is named now) is
another that does a great job at this. It's really hard.
Regardless, I would love to get suggestions on particular elements
that you dislike, because Eclipse/WOLips is open source and we can fix
them ... It's very likely that you have a lot of great ideas that I'm
just not even considering because I've been using Eclipse/WOLips too
long to notice them anymore. I was serious when I say I want the tools
to not suck. The less they suck, the easier it is for us to develop
applications and the more easily we can train new developers.
Long story, and I will report if we run in a wall. Basically it
works if you know when and how many times you need to open/close
projects, clean them, restart eclipse, restart it with -clean, and
when to go to the local church for a short pray. To get this
pattern right just takes so much time... And of course all usual
stuff with EOGen etc.
For the record, this is 99% of the time WOLips and its more complex
build system requirements over a "normal" Java project (rather than
Eclipse itself). What this means is that it's also fully within our
control to fix these. The cases of these weird build problems have
been decreasing, but they're still not gone. Build system is one of
the things that's on my short term hit list ...
* open/close projects - this is definitely one of the mojo fixes for
things. If you get reproducible cases of bugs that require this,
definitely log them, because I'm always on the lookout for them.
* clean project - After a crash, or after changing compiler/validator
settings, etc this is probably always going to be required (because of
eclipse's incremental compiler, it needs to be in a known state). But
cleaning "just because" totally sucks and is still necessary
occasionally. I'm hoping some of the upcoming cleansing of the WOLips
build process will make this less common.
* Other than upgrading, you should NEVER have to restart Eclipse
(should != don't right now, I mean in the grand scheme). I find this
to be totally unacceptable. The only ones that I know of for sure
right now are /Lib/Fram reloading (which I mentioned is on the way
out) and I believe there's a classpath caching bug in Entity Modeler
in SQL generation under certain circumstances that I haven't totally
nailed down yet.
* eclipse -clean should never have to be run ... This is only if you
install plugins in a weird way. I'm actually not aware of any case in
WOLips that requires this now, so you can at least remove this out of
your Mojo Dance :)
You are right, and I will spend next few minutes in the corner
very ashamed. Should I fill bug reports to Wonder Jira?
You may come out of timeout now :) WOLips Jira, actually ... http://issues.objectstyle.org/jira/browse/WOL
My P.S.'s are an expression of huge frustration. About the insane
decision of Apple, and about the fact that few Eclipse advocates
are so vocal, then almost no other opinion could be expressed on
this list. In private I often receive emails telling me that I am
not along. But as it happens in every community, many people are
quiet, and one would get the feeling I and Ken are the only black
sheep here. When I am able to state that the UI of Eclipse is a
horror without being bashed, and when the rights of the developers
of using nice elegant native tools are accepted, I will stop
writing P.S.'s.
I get emails, too (admittedly, more pro than con, but I'm sure people
email who they think will be a sympathetic ear :) ) .. And I wish
people would speak up more, because it helps the entire community to
have discussions of these topics. I just want productive discussions
on it, not "snippy asides." Like I mentioned above, we are in control
of these tools at this point. We can change them however we'd like.
Again I bag to differ. My hypothesis is that Apple just followed
the most vocal people of the Wonder community. This was a very
comfortable decision for then because it freed them of investing
in tool support. If the same people would spend the same mental
and vocal energy on supporting the old WO tools, we could be in
completely different environment now.
You're overlooking the other possibility, which is that Apple maybe
isn't WILLING to invest in WO tools, and the longer they choose not
to, the higher the risk that a WO tool would break in a future
release, which would potentially put the entire framework release at
risk. In this interpretation of events, WOLips freed the core
frameworks to grow with substantially less risk.
As far as supporting the old WO tools, I'm not exactly sure how we
could have supported them. Could we have begged Apple louder to
replace them? It had been years since anything really had come out of
Apple in this regard. None of the Apple tools support a public plugin
architecture, so begging was really the only other choice. So it was
either that we try to provide nice replacements to the tools (which is
the route we chose) or we beg louder, which hasn't had much impact on
Apple over the past 5-7 years.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden