[news.eclipse.platform.rcp] Re: [Error] org.eclipse.swt.SWTError: No mor

[Ed Merks <merks@xxxxxxxxxx>]

Shawn,

Comments below.

Shawn Spiars wrote:
> Ed,
>
> I kind of thought you might disagree.  Comments below.
>
>
> Ed Merks wrote:
> > Shawn,
> >
> > Comments below.
> >
> > Shawn Spiars wrote:
> > > Ed,
> > >
> > > Yes, I think it may have been a human error, rather than a machine 
> > > generated error. It was a couple of years ago so I don't remember
> > > the details.
> > >
> > > Sometime I would be happy to talk to you about why I dislike Model 
> > > Driven Architecture
> > I can imagine the reasons (I've heard so many over the years) but I'm 
> > highly unlikely to agree.  :-P
> > > and why I believe that models and machine generated code (EMF) 
> > > cannot create user-friendly, intuitive, or easy to maintain user 
> > > interfaces.  
> > I totally disagree.  If you can write it by hand, you can machine 
> > generate it.  It's all about automating patterns and best practices.  
> > I think many developers just have a pathological need to do menial 
> > work in order to keep their sense of control intact.  
> So because I don't like MDA I have a pathological need to do menial work
> in to order to feel in control?  Wow, that's a leap.  I guess I hit a 
> sore spot.
As you can imagine I've heard many arguments so while I don't know your 
personal reservations I do know that for many people it does stem from a 
feeling that they need to control every character in every file 
manually. Of course people don't like to think of it that way.  In any 
case, I was merely showing you the shoe that fits for many.  If it fits 
you and that's hits a sore spot, so be it.  I'm of course much happier 
if that shoe doesn't fit you and you have more substantial reasons.  I'm 
not buying into argument, that "my work is an art" and "I can't practice 
my art properly with modeling".

In any case, I suspect that I've overlooked one important word in your 
sentence, the "user" in user interfaces.  EMF's primary focus in to 
generate your data model's interfaces.  I think the structured views 
supported by EMF.Edit are cool, and the command framework is very 
useful, but the properties view is a poor excuse for a user interface...
> Those were the people who
> > figured assembler was the only way that give them the control they 
> > needed.   Let's see how you would write code that notifies as things 
> > are changed, including changes being made to a list.  I'll bet your 
> > intuition will change once you've figured out how to do it...
> A users intuition doesn't change based upon the time savings derived 
> from machine generated code.
It does change as they learn and as they solve problems themselves 
manually.  There is a such thing as best practices and design patterns 
that can be relearned from trial and error by each user or can be 
generated automatically.
> > > User interface development is an art, not a science.
> > But writing getters and setters that match, implementing interfaces 
> > and implementations that correspond, supporting a factory pattern for 
> > creating them, and so on, is all menial work.  While some may be 
> > satisfied doing that over and over, others will rise above it in more 
> > ahead more quickly.
> I agree that generating getters and setters is menial work and I 
> appreciate tools that can accomplish this task for me.  My point is 
> that an application is much more than a bunch of business rules and 
> machine
> generated controls stuffed into a properties view table.  Yes, it
> may be functional, but from a UI design standpoint it's really crappy.
In general, I would argue that you should be able to focus the parts of 
the application that need human attention, i.e., the cool things that 
require creativity and leave the menial tasks to the machines, i.e., 
generating a data model that supports notification, serialization 
concerns, basic data binding hooks, and so on.  Just as you build tools 
for others, learn to use them effectively to automate as much of your 
work as possible.  The properties view is indeed crap, but with 
Eclipse's data binding frameworks, you can spend your time building a 
slick UI without managing trivial details that will just work automatically.
> > > It's so much more than just a bunch of model objects stuffed in a tree
> > > or table with actions attached.
> > Indeed, but far too much time is spent on menial things rather than 
> > the higher level tasks. If you can draw a box X with nested box y of 
> > type String and this implies an interface X with a getY/setY as well 
> > as an implementation class for it, with a y field to store the value, 
> > and a factory method to create an X, all that crap is not art, it's 
> > menial.  I used to be on your side of the fence. Drawing boxes with 
> > labels used to seem incredibly stupid to me, but I realize now that 
> > the only thing stupider is to do ten times as much work to arrive at 
> > the same implied design as was expressed by the stupid picture.
> If a UI was simply a bunch of boxes and labels then I would agree with 
> you.
The boxes and labels are for specifying your data model, just as the 
program you write is a bunch of identifiers with punctuation; they're 
entirely equivalent and you can convert between them.    None of this is 
to be confused with the pretty UI you are trying to build for your end 
user application.
> > I'll be at EclipseCon, you're welcome to try to argue your point.  
> > Probably the Modeling BoF won't be the most receptive audience though.
> No thanks, I won't be attending any modeling sessions at EclipseCon.
You don't appear to be very open minded.  I didn't intend to insult you, 
but I suspect I did.   I think at one extreme you are saying that MDA 
can't generate a complete polished visual application based on simple  
intuitive code similar to what you'd write by hand, therefore all MDA is 
bad.  Yet I know from personal experience that I can most certainly 
generate a completely functional data model, i.e., interfaces with 
implementation classes and a factory to create the instances.  The code 
is just like what I'd write by hand, because in fact how the templates 
for generating the code were arrived at by templatizing the hand written 
patterns.  With the XSD model implementation, there's about 100,000 
lines of code, where 60,000 lines of it was generated and the remaining 
code was all hand written to implement various sophisticated 
algorithms.  This was all done in the course of three months.  
Absolutely I saved months worth of work with this approach and produce 
the same API  would have produced by hand.  It let me focus on the two 
parts of the task that were fun: condensing the prose of the XML Schema 
specification into a high level API (model), and implementing the 
algorithms described in the specification.
> > Given that you can model any Java interface with Ecore, including 
> > generics, it will be hard to make the case that there is something 
> > you can't do.  But it will be interesting to see if you have a new 
> > argument I haven't heard before.  I'm always excited to hear a new 
> > reason with actual substance.  :-P
I really was hoping to hear an interesting new reason why modeling 
should be avoided.  Every couple of months somebody does say something 
substantial that makes me think about stuff that could be improved.  I 
agree that the state of the art for generating a good user interface is 
still quite poor.  Though mind you, GMF's ability to generate the 
scaffolding for a graphical editor is quite amazing, and from that 
working starting point you can do lots of creative things by hand to 
polish it.  But I've also heard people complain about the generated code 
being poorly structured and repetitive (not making use of inheritance 
for example).  So I think there remains large areas of improvements.

It's often interesting to me, that people writing a schema don't think 
they are modeling so I like to find out what it is they think they're 
doing when they are carefully describing their data structures using a 
formal language.  It's just modeling with a different name.  Same goes 
for people writing interfaces with methods to describe their data 
structures.  It's just more modeling thought of in a different way.

I know many people will continue to think that modeling is stupid.  
That's okay.  I know there's always at least a grain of truth in every 
perspective.  But the broadest perspectives are those that see truth 
where others see contradictions...
> > > Shawn
> > >
> > >
> > > Ed Merks wrote:
> > > > Shawn,
> > > >
> > > > EMF uses registries for the image management.  Was it a programming 
> > > > error on your part or is there something being overlooked in EMF?
> > > >
> > > >
> > > > Shawn Spiars wrote:
> > > > > Michael,
> > > > >
> > > > > You can use sleak to track the creation and disposing of SWT 
> > > > > resources.
> > > > > It helped me find an image that was being created over and over in 
> > > > > some
> > > > > EMF factory or adapter whatchamacallit.
> > > > >
> > > > > http://www.eclipse.org/swt/tools.php
> > > > >
> > > > > Shawn
> > > > >
> > > > > Ed Merks wrote:
> > > > > > Michael,
> > > > > >
> > > > > > Gosh, I'm not sure how best to track these things.  There is 
> > > > > > indeed a system wide limit as well as a per process limit, if I 
> > > > > > remember previous postings correctly.  Hopefully someone will 
> > > > > > have details, or googling will turn them up
> > > > > >
> > > > > >
> > > > > > Michael Heiß wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > For images i use the ImageRegistry so i think this cant be the 
> > > > > > > source.
> > > > > > > How can i detect widgets that i do not dispose properly?
> > > > > > >
> > > > > > > When i look in the task manager i see the following result:
> > > > > > > memory: 46.200 K Handles 869
> > > > > > > UserObjects: 1150
> > > > > > > GDI-Objects: 1120
> > > > > > >
> > > > > > > What is the limit on a computer running windows xp?
> > > > > > >
> > > > > > > Best Regards
> > > > > > > Michael