Eclipse 4.0/eclipse-e4-04-07-08

This conversation took place on April 7th, 2008 before the logging mechanism was in place in #eclipse-e4.

[09:08am] tomsontom joined the chat room.
[09:08am] tomsontom was promoted to operator by irc.freenode.net.
[09:08am] the_mcq joined the chat room.
[09:09am] the_mcq: Hello.
[09:09am] tomsontom: hi
[09:09am] pnehrer joined the chat room.
[09:09am] blupi1 joined the chat room.
[09:10am] paulweb515 joined the chat room.
[09:10am] rcjsuen joined the chat room.
[09:10am] benny`work joined the chat room.
[09:10am] benny`work: wha 
[09:10am] paulweb515 was promoted to operator by you.
[09:11am] the_mcq: re "EMF supports fully dynamic instances that involve no class generation." -- so is this the direction that is being taken in the prototype?
[09:11am] merks joined the chat room.
[09:11am] tomsontom: I'm also not eager to create a huge bunch of classes but my frist drop will simply because it's easier to see if my model is correct
[09:11am] ChanServ made this room no longer a secret.
[09:11am] ChanServ changed this room to require operator status to change the topic.
[09:11am] merks: Cool.
[09:11am] tomsontom: and doing the correct thing
[09:11am] Pookzilla: paulweb515: are you going to register this with chanserv and such?
[09:11am] paulweb515: Pookzilla: done
[09:13am] merks: I think there's kind of a tradeoff between having nice generated interfaces that provide statically typed APIs, which make it much easier to use the model, but bloat the system with byte code, verses having to do everything through plastic APIs that provide no compile time safety...
[09:14am] brau joined the chat room.
[09:14am] Tortoose joined the chat room.
[09:14am] GUIs-R-Me joined the chat room.
[09:15am] the_mcq: One of the non-modelling topics I'm interested in is trying to understand whether there is anything that we can do about our current permgen usage. Reducing the number of inner classes that created seems like the only transformation that can be done without drastically affecting the code. The obvious place where this happens is listeners, of course.
[09:15am] Topic changed to "Eclipse 4.0 discussions - everybody welcome - http://wiki.eclipse.org/E4" by paulweb515.
[09:15am] njbartlett joined the chat room.
[09:15am] the_mcq: merks: I'm honestly not sure I believe the use of the word "much".
[09:15am] merks: Unfortunately even the smallest class seems to have very significant space overhead.
[09:16am] ijuma joined the chat room.
[09:16am] merks: I'm not sure how you can say that...
[09:16am] merks: I look to DOM as the perfect example of the fact that a plastic API is not easy to use.
[09:16am] merks: DOM solves all XML processing problems in one fell swoop.
[09:16am] the_mcq: I understand that statically checking things is useful, but I'm an old Smalltalker: As long as an object has the fields I need, I'm happy to use it. I don't actually care what it's class is.
[09:17am] merks: I think Tom's pointed out a few times already that using a plastic API means that all constraints on what's well formed at dynamic, not compile time.
[09:18am] merks: So you can never know whether a given property makes sense or whether you've created something that's well formed, statically.
[09:18am] the_mcq: (ya, as I said, I'm late to the party. :-()
[09:18am] merks: JDT offers name completion so you can type get..  and then it suggests all the things you can get.
[09:18am] merks: And you know what type of thing you get back.
[09:19am] merks: So now I can type x.get("....", but what can I type in "..."?
[09:19am] merks: I'll have to hunt for documentation.  If I mistype, oops, I'll find out later.
[09:19am] merks: Now what comes back is a java.lang.Object.  Hmmm.  I wonder what type of thing it might be.
[09:19am] GUIs-R-Me: Just to muddy the waters here....one of the characteristics of any implementation we choose is that it must have some support for 'late binding' at a fine-grained lavel
[09:19am] merks: More hunting of documentation...
[09:19am] merks: hehehe
[09:19am] merks: What does that mean?
[09:20am] GUIs-R-Me: We are extensive users of lazy loading and we'd like, for example to have the property representing the ViewPane to exist as a string -until the first reference- (when it'll get 'magically' replaced by the real entity
[09:20am] the_mcq: I see the objects in the UI model as having two different kinds of attributes: "static" things that describe the underlying structure, and "overlayed" things that are a side-effect of applying a particular styling engine to the object. <- This latter set could be completely different based on what engine you are using. It isn't clear how to represent this with static typing.
[09:21am] Kellindil joined the chat room.
[09:21am] the_mcq: In any case, the argument about JDT is just saying "Our existing tooling can do this because of static typing". It's not saying "The only way you can have completion is via static typing". I'm perfectly happy to discuss richer tooling that could do it for the dynamic case.
[09:22am] merks: That's like lazy loading/demand loading of classes or metadata...
[09:22am] blupi1: the_mcq: why would you create attributes for information that can be computed?
[09:22am] GUIs-R-Me: I agree, most of my 'GuiModel' would get replaced by the styler. The remaining properties affect 'structural' things like defining the active view/perpsectove...
[09:23am] merks: Shouldn't the viewing be done in a way separate from the intrinsic things in the model.
[09:23am] the_mcq: blupi1: Sorry, I failed the "understands how models work" test: What does your question mean?
[09:23am] merks: Given that you might want to view the same things in three different ways, say, isn't it a bad idea to adding view information directly to the model instance?
[09:24am] brau left the chat room.
[09:24am] GUIs-R-Me: absolutely....unless it -is- a model of a particular view
[09:25am] merks: I see.
[09:25am] GUIs-R-Me: but you point is well taken and may bolster my case...I use the -same model- to create the WorkbenchModel content provider -and- the actual perspective widgets
[09:25am] paulweb515: merks: that's part of what we need in the workbench model ... our model of window, view, editor parts, toolbars, menus, etc ... but they will be model, rendering for us should be plugged in elsewhere
[09:27am] merks: Yes, I might be getting confused when your model is actually the view.  Not sure how MVC works with M == V...
[09:27am] paulweb515: merks: it causes us some problems as well 
[09:27am] GUIs-R-Me: This includes re-using the IMAGE and LABEL properties for Views/menus...etc. Right now I can have a 'generic' ContentProvider that only requires a label but if EWorkbench is statically typed I'd need to use a specific one wouldn't i ?
[09:27am] blupi1: the_mcq: On second thought, it might have been me who failed the test - I thought that attributes like "fgColor" would not be defined on the styled objects themselves. I thought this would be separatable, but I think I agree with you now - you would want to be able to set the fgColor to a different value than the computed one, by setting a property on the stylable object itself.
[09:27am] GUIs-R-Me: Not quite what I meant..
[09:28am] GUIs-R-Me: that was to ed's reply...;)_
[09:28am] benny`work: paulweb515, can we log this chan? i think it would be worth
[09:28am] paulweb515: merks: we think we can take a better pass of the workbench model if we do separate it into a model (that talks about our lifecycle, our objects, our layout) and some kind of renderer that actually converts that to SWT or Flex or ActionScript (in theory) ... this experimentation should be worth while
[09:29am] paulweb515: benny`work: We could invite KOS-MOS in ... or we can post transcripts regularly to the mailing list
[09:29am] paulweb515: I have no preference
[09:29am] merks: Yes, I think that's really important.  At EclipseCon Jim van Dam gave a cool quick talk...
[09:29am] merks: I attached his outline to a posting.
[09:29am] Kellindil: benny`work, +1 on this, logs of this discussion might be interesting
[09:30am] Pookzilla: can chanserv log for us
[09:30am] Pookzilla: ?
[09:30am] benny`work: not sure kim
[09:30am] merks: I though it was very neat how he kept the high level "what should the GUI generally do" separate from "what technology should render it" and finally "how should it be formatted and made to look petty in different ways".
[09:30am] rcjsuen: paulweb515: KOS-MOS doesn't log, unfortunately.
[09:30am] benny`work: but afaik kosmos can't help us with logging
[09:30am] GUIs-R-Me: Ed, that's the idea :_
[09:31am] GUIs-R-Me: Also should have some place for model 'logic'
[09:31am] paulweb515: rcjsuen: I can always ask nitind how he set it up for #eclipse
[09:31am] merks: I've been arguing with folks internally that we spend a lot of time building a fancy GUI and then the techology changes and we have no metadata to represent the design of our GUI that can be reused...
[09:31am] GUIs-R-Me: Too true
[09:32am] GUIs-R-Me: trust me folks I understand the power of meta=data (I did the Transform Apply GUI for Rational Studio Modeller...it's big thing was Model-to Code trandofrms
[09:33am] merks: Yes.  And sometimes what's doubly cool is if you don't have to generate any code at all.
[09:33am] merks: After all, if you have a description of what you need, you can probably emulate the beahvior form the metadata.
[09:33am] GUIs-R-Me: But, again, all meta-data isn't EMF and the same questions arise...is there 'too much' information there for what we require
[09:34am] merks: It doesn't really matter the form of the meta data (well actually it does) but assuming for a moment it doesn't...
[09:34am] merks: The important thing is to have a description of the "intent".
[09:34am] merks: You can use that to generate code...
[09:34am] merks: But you can use it to emulate the behavior of the code that you would have generated.
[09:34am] GUIs-R-Me: absolutely !! quick, everybody agrere ! 
[09:35am] merks: It goes back to mcq's point about too much byte code.
[09:35am] merks: But anyway, when it comes to data, I believe it's fundamentally import to consider, what is the metamodel for that data.
[09:35am] merks: That way, given any data you might not have seen before, you can reason about it.
[09:35am] merks: Script against it.
[09:35am] merks: Know how to create, modify.
[09:36am] merks: But I'll start preaching if I'm not careful. 
[09:36am] GUIs-R-Me: Ed, what about my exemplar? It's suitable for 'typing' and default values but lacks finesses like min/max values for ints...
[09:36am] GUIs-R-Me: Ed, I can already see your eyes glowing...it's OK mine do the same (that's when I have to be careful..;-)
[09:37am] merks: I'm not all that familiar with the "exemplar" style.  It seems to me that if I make a mistake, it becomes exemplary.  I that a gross mischaracterization?
[09:38am] blupi1: merks: no, just like any mistake in the metadata would be disastrous.
[09:39am] GUIs-R-Me: You make a 'property bag' containing the properties that a given 'class', containing a (default?) value. This can then be used to 'type check' instances and take action
[09:39am] merks: It's hard to characterize what's a mistake in the metadata.  Certainly there are rules for well formedness.  Ie., a feature must have a type.  Types must not be circular...
[09:39am] blupi1: ...think class-based vs. prototype-based inheritance
[09:40am] merks: SOmeone tried to explain the prototype thing to me because that's how JavaScript works I gather.
[09:40am] GUIs-R-Me: It contains the 'minimum' set of properties, their types and could also define the default values
[09:40am] merks: So once you add a property and set it to be an int value, does that mean it can't have a float value anymore?
[09:41am] merks: I'm certainly understanding the different angles to this issue more...
[09:42am] GUIs-R-Me: No, the exemplar simply describes the 'desired' type. That's my approach for 'lazy loading'..you can have a string in the model but have a desired 'type' of "Font"
[09:42am] GUIs-R-Me: then, the 'get' will do the conversion (through some registed map)
[09:42am] merks: Perhaps taking a step back...
[09:43am] merks: Do folks envision this model thing the platform is using as what folks will want to use for their own domain models?
[09:43am] GUIs-R-Me: Voila, lazy loading made easy
[09:43am] GUIs-R-Me: yes, most explicitly
[09:43am] blupi1: merks: not necessarily
[09:44am] blupi1:
[09:44am] GUIs-R-Me: I'm trying to get it even closer to the core...I'm trying to make the case for equinox because I think it can solve some of their 'dynamic' loading issues'
[09:44am] merks: EMF allow you to create metadata (Ecore instances) on the fly and then create instances of those...
[09:44am] merks: So this dynamic aspect is certainly supported.  All without generating code for any of it.
[09:45am] GUIs-R-Me: By -reusing- the same listeners...less code, not no code
[09:45am] GUIs-R-Me: symmetry is the key
[09:46am] merks: There's no finer symmetry than the fact that the model of a model is a model.  
[09:46am] merks: hehehe
[09:47am] GUIs-R-Me: In the GUI model it's expected that -all- clients use GUI_LABEL for strings that appear in lists, trees, menus... and BG_IMAGE for images that appear in the backgrounds of controls
[09:47am] GUIs-R-Me: that's recursion...:)
[09:47am] merks: So does that mean that if someone has a domain model already, they'll need to create a separate GUI model?
[09:47am] GUIs-R-Me: no
[09:47am] merks: And if they render one object in two different ways, they'd need to separate GUI model instances?
[09:48am] merks: I think I keep getting confused by MVC where M == V and I always think of it as M != V...
[09:48am] GUIs-R-Me: If they're using my ModelElement all they'd have to do is add a LABEL propetry to their bag...how about EMF?
[09:49am] blupi1: I would say yes to "they'll need to create a separate GUI model".
[09:49am] merks: What if it already has a LABEL property but now they want a different view of it?
[09:49am] blupi1: Not necessarily a model in the sense that you wrap all existing domain model objects in GUI model objects.
[09:49am] GUIs-R-Me: as long as they want the same label (surely the most common case) they jsut re-use the mdoel
[09:50am] blupi1: But in the sense that depending on where your objects show up in the UI, you need different content and label providers.
[09:50am] merks: And if not, they build another model entirely?  Completely duplicated except for the label proeprty?
[09:50am] GUIs-R-Me: Not in a property bag world, this is an artifact of string typing
[09:50am] merks: I thought that's why we have MVC so that we can separate the model (the intrinsic data) from the view of it...
[09:50am] blupi1: I.e. instead of wrapping each individual object, you provide a facade to a certain part of your model.
[09:51am] GUIs-R-Me: In the case of folks who are -not- using ModelElement as their base model this is exactly what they'd do
[09:51am] merks: So sometimes you stick properties directly with the object, in order to view it, and other times you build facades for them...
[09:51am] GUIs-R-Me: depends on the underlying model
[09:52am] blupi1: I think I agree with merks here, not GUIs-R-Me.
[09:52am] GUIs-R-Me: that ok 
[09:52am] merks: From my experience, folks want to design models that are "pure".
[09:52am] blupi1: +1
[09:52am] merks: I.e., that have nothing to do with any viewing techology.
[09:52am] zx|india joined the chat room.
[09:52am] merks: They can use swing to render it.
[09:52am] merks: Or SWT.
[09:52am] merks: Or view it in the web.
[09:53am] merks: it's all the same model that's persisted a certain way, can be exchanged, shared, and so on.
[09:53am] merks: All viewing is done separately.
[09:53am] GUIs-R-Me: Folks, my ModelElement does -not- have any reference to UI/SWT/dogs/cats...
[09:53am] GUIs-R-Me: its just a small/simple API that regular folks can get their hands dirty with (think mashup)_
[09:54am] merks: I'm just losing sight of the split between model and view that's so important to MVC.
[09:54am] merks: I always considered things like content and label providers to be such excellent things that provided exactly the kind of VC part of MVC that was needed.
[09:55am] GUIs-R-Me: Ed, for GUI models there are actually two parts; the 'semantic' model (i.e. Table, four legs + top) and, for every place where a part of the semantic model appears in teh GUI, the information needed (label/image...) to show it in that context
[09:56am] merks: And if the table is showin in four different views, each using a different icon and label?
[09:56am] GUIs-R-Me: In past lives I've called this 'surfacing' the model (i.e. it gets to the glass)
[09:57am] blupi1: I would argue that you then need four different label providers, but can use the same content provider.
[09:57am] merks: Indeed!
[09:57am] GUIs-R-Me: Ed, be reasonable...if someone really wants the same object to appear with different labels everywhere shouldn't they have to pay a bit more that the regular folks who are happy to get it into a tree/list and a dialog all for free
[09:58am] merks: What a minute.  I'm not being unreasonable.  I know users do this all the time.
[09:58am] merks: In one place they want the label to be the fully qualified name.
[09:58am] GUIs-R-Me: Pathological  cases are somewhat less interesting than green threads IMO
[09:59am] merks: I another they context shows the quallification and they don't need it.
[09:59am] GUIs-R-Me: Then they'd override -their- label provider
[09:59am] merks: All I'm pointing out is that MVC is all about keeping the model and the view separate.
[09:59am] merks: So putting view properties on the model seems to go against the grain.
[09:59am] merks: I can understand if the model is inherently representing a view...
[10:00am] merks: But most models are intended to be pure.
[10:00am] merks: I.e., the table with legs thing.
[10:00am] merks: Might be intended for some CAD/CAM thing
[10:00am] merks: You don't put icon properties on it...
[10:01am] the_mcq: I believe the purpose of this particular model is to allow application code to easily manipulate this particular UI. For example, I don't think it will ever have "domain" objects in it.
[10:01am] blupi1: merks: Btw, I agree that the idea of content providers and label providers is excellent, but I should also say that I am not happy at all with the concrete realization of this idea in JFace, because content providers have an odd dependency on a single associated viewer and do not specify a listener API. This makes them non-composeable.
[10:02am] merks: Yes, I think this is a point of confusion for me.  Obviously for many folks (most) the model is a domain model...
[10:02am] the_mcq: The thing I use to drive my thinking is "If I was going to write some javascript to modify the appearance of the UI, what would it look like?".
[10:02am] blupi1: the_mcq: yes, our domain is the Workbench, and in that domain, things like views and editors do have an icon, and a label, etc
[10:03am] the_mcq: (btw, I'm in and out of my office, and so am only participating intermittently.)
[10:03am] merks: I think tom will demonstrate that EObject.eGet()/eSet is pretty much just like model ModelElement is doing.
[10:03am] merks: And like what SDO is doing...
[10:03am] merks:
[10:04am] merks: Good you tell us or we wouldn't know.
[10:04am] merks: Interestingly, we even have something much like the getChildren/getParent thing, but perhaps more "well structured".
[10:05am] merks: You can define any model and make certain (often many) of the references be "containment".
[10:05am] merks: These defined the tree (parent/child) structure.
[10:05am] merks: So folk any EObject, eContainer returns the one unique container (or null).
[10:05am] tomsontom: GUIs-R-Me: sorry for my silence had to help on of my employees to write meaningful unit-tests 
[10:05am] merks: And EObject.eContents() returns all the contained children.
[10:06am] tomsontom: GUIs-R-Me: you talked about reusage of LABEL and IMAGE, is this answered already?
[10:06am] merks: So its like the getParent/getChildren() thing, but is implicit from the more strongly typed information in the model.  So you could script against the tree, while still having a "regular" API for other uses.
[10:07am] the_mcq: So, modulo reasonable looking JS code, the only other constraint that is interesting to *me* is performance; both speed (natively and as an over-the-wire rep) and space (in mem and permgen), particularly as things scale up.
[10:08am] merks: I've not taken measurements for a while, but the last time I did,  EObject.eGet(EStructuralFeature) was faster than HashMap.get() with a String key.
[10:08am] merks: EObject.eGet(featureIndex) is even faster than feature-based lookup.
[10:08am] GUIs-R-Me: tomsontom: I'm not sure -anything's- been answered 
[10:08am] merks: No, me too. 
[10:09am] merks: I think we're still filling the space with questions.  And I think unfortunately I have a gap in my when is a model a view and when is a model separate from a view. 
[10:09am] blupi1: Feature-based lookup in EMF has the added advantage to be not as brittle as string-based lookup as you refactor your model.
[10:09am] merks: Yes.  ANd of course strong typing.
[10:10am] merks: If you do EObject.eSet(feature, object) it will guarentee that object is the right type of object.
[10:10am] GUIs-R-Me: This is all true....and I'll take it all (but not at the cost of having the public API be so complex that folks won't adopt it)
[10:11am] GUIs-R-Me: Everything I'm hearing could, I think, take place 'under the covers'
[10:11am] tomsontom: GUIs-R_Me: but is a weakly type really easier to use?
[10:11am] merks: It does take place under the covers...
[10:12am] merks: No, it's hard to use.
[10:12am] merks: Exceedly error prone.
[10:12am] tomsontom: infact when using weak-typed API the Documentation of the model is your API
[10:12am] GUIs-R-Me: Strong typing just means that, when you ask for IMAGE you can be -sure- that you're going to get back an Image no safety checks needed
[10:12am] GUIs-R-Me: tom, you got it!
[10:13am] merks: The "just" is very important isn't it.
[10:13am] GUIs-R-Me: ed, it's -not- hard to use...the Ruby folks don't think so
[10:13am] merks: It means when you set the image, you must set an image.
[10:13am] merks: Not set crap and later on some code fails because of crap in crap out...
[10:14am] GUIs-R-Me: Actually, in my case I set a String but get a SWT.Color
[10:14am] merks: Like SDO style type conversion on the fly.
[10:14am] GUIs-R-Me: Again, usefull for both scripting and lazy loading
[10:14am] paulweb515: benny`work: I've put in a request for channel logging
[10:14am] merks: It's a cool idea too, but involves lots of instance ofs from my experience with SDO.  I.e., the cost is quite high.
[10:15am] GUIs-R-Me: There's a bazollion different API's for this ("you're in a twisty maze of passages all (somewhat) alike"...;)
[10:15am] merks: hehehe
[10:15am] merks: Let's make a new maze, much like the others?
[10:16am] GUIs-R-Me: No, let's make a simple straightforward corridor
[10:16am] merks: Let's put the death traps in new places.  
[10:16am] merks: Ah, so all those other foolish people never consider that it could have been so much simpler?!
[10:16am] merks: Silly them!
[10:16am] merks: hehehe
[10:16am] blupi1: GUIs-R-Me: "set a String but get a SWT.Color" does not sound simple and straightforward to me.
[10:17am] merks: Or an RGB value, specified as a string, or array of ints...
[10:17am] GUIs-R-Me: tomsontom: Tom, do you want to go offline to talk about your demo??
[10:17am] GUIs-R-Me: blupi1: It is for the user.... myView.bgColor = "255, 0, 125"
[10:18am] the_mcq: Putting types on fields is bad. I don't care whether it's stored as an image, a file name, or a URI. The important thing is that I can get something I can display when I ask for it.
[10:19am] merks: So make the type be java.lang.Object.
[10:19am] the_mcq: To me this says the types should be all Object (or String.  ) with validation built in.
[10:19am] the_mcq: Yes.
[10:19am] GUIs-R-Me: Object
[10:19am] merks: I can't take at face value that types are bad...
[10:19am] the_mcq: They *aren't*.
[10:20am] the_mcq: They just don't map well on to Java classes.
[10:20am] merks: Are you another one of these smalltak guys?  
[10:20am] merks: Just kidding.
[10:20am] the_mcq: What I want is a good representation (in Java) for the structure of the object, and separate from that a good model for the type.
[10:21am] GUIs-R-Me: Also, the format for a string / font... may vary from one rendering lpatform to another (i.e a different converter could return GWT.Color)
[10:21am] merks: I have noticed that the use of smalltalkd leaves an indelible mark...
[10:21am] the_mcq: now you're being mean. <g>
[10:21am] merks: Hopefully my jokes are taken as such.
[10:21am] merks: Clearly I'm tainted by "modeling" as a religion...
[10:22am] the_mcq: (Actually, I define myself as a Scheme hacker, to tell the truth)
[10:22am] merks: hehehe
[10:22am] merks: So lets assume for a moment that we were modeling purests...
[10:22am] merks: We'd want to build a GUI model that would be used on any rendering system.
[10:23am] GUIs-R-Me: within limits
[10:23am] the_mcq: q 1: why
[10:23am] merks: So we'd come up with a data type that represented a color in a "generic way" that didn't depend on SWING or SWT...
[10:23am] merks: And then we'd convert it to whatever rendering target we used.
[10:23am] GUIs-R-Me: not possible (fonts have different face names on different platforms
[10:23am] the_mcq: Generic solutions are only better, if we actually believe that will happen.
[10:24am] merks: So you don't want to present to be modeling purists. 
[10:24am] GUIs-R-Me: that's what CSS is for....the values for platform specific stuff comes from a platform psecifc CSS
[10:24am] the_mcq: html has a story for different fonts on different platforms, we would want to do something similar.
[10:24am] merks: Yes, that's all I'm driving at.
[10:24am] merks: As a specific example...
[10:25am] merks: EMF item providers are deliberately designed not to be dependant on Eclipse.
[10:25am] merks: Folks could use them with SWT.
[10:25am] merks: So images are represented as URIs.
[10:25am] merks: Similarly for colors and fonts.
[10:25am] merks: Fonts are a hard problem as you say...
[10:25am] GUIs-R-Me: Do you have a resource management storyZ?
[10:25am] merks: Because what point is there in mentioning helvetica when it might not exist.
[10:26am] merks: In any case, all these URIs are used to in a registry...
[10:26am] GUIs-R-Me: We take -great- care to re-use Colors/Fonts and Images to save system resources
[10:26am] the_mcq: Note: Have we talked about the specific example of the specific model that Eric's demo uses? I.e. Regardless of the representation, is the *content* of Eric's model sufficient. (Is that where you're going merks?)
[10:26am] merks: To map from the URI to the right object specific to the rendering system.
[10:26am] merks: hehehe.  Am I going somewhere you ask?
[10:27am] merks: I think it would be really cool at some point to have a call with a web demo...
[10:27am] khussey joined the chat room.
[10:27am] merks: I'm really only talking about abstract general principles as I've seen them in the modeling space.
[10:27am] merks: Things like that StUIML proposal seem very interesting to me and see quite related to what I see happening here.
[10:28am] GUIs-R-Me: Please note that I've spent more time in this chat and over the weekend that it took me *To WRITE the complete ModelElement' impl* !!
[10:28am] merks: hehehe
[10:28am] merks: This is the problem of open communities.
[10:28am] merks: They suck back your time like no one's business.
[10:28am] the_mcq: And does the model need to be described in terms of the specific "kinds" of things it can take (e.g. bgColor is the background color, which can be a web color name, an RBGT tuple, or an instance of an SWT RGB or an SWT Color...
[10:29am] merks: I accomplish a lot more in my evil secret lair when one bothers me. 
[10:29am] GUIs-R-Me: or a formatted string (whose format could be differnt platform-to platform)
[10:29am] GUIs-R-Me: lol
[10:29am] GUIs-R-Me: I saw tre blog
[10:29am] merks: Which one.  The m4 one.  That was fun.
[10:29am] merks: I have a deeper one for today!
[10:30am] merks: At this point, I think lots of the issues are on the table and folks like Tom are prototyping so that we can kind of get onto the same page...
[10:31am] GUIs-R-Me: perfect
[10:31am] merks: Would a call in meeting with a web hosted demo make sense at some point?
[10:31am] GUIs-R-Me: I have no doubt that Tom will clean up my demo code as well 
[10:33am] merks: I keep saying so many nice things about him.  His ego might over inflate.  Maybe we should diss him a little. 
[10:33am] the_mcq: I could imagine getting together once a week on this topic. To my mind "modeled UI" is one of the big ticket items (like "flexible resources").
[10:33am] tomsontom: GUIs-R-Me: I had to read up what I missed and now I need to get some work done  but I have time in the evening
[10:33am] merks: That would be cool.  It would help create kind of an extended team feeling...
[10:33am] GUIs-R-Me: sure, even better might be checking in the demo code (Tom, please make a copy if you're going to end up destroying my current structure...;-)
[10:34am] merks: Improving/destroying.  What's the difference? 
[10:34am] tomsontom: GUIs-R-Me: I have a seperate plugin named presentation.pure.emf
[10:34am] merks: Oh, there I go being mean again.  Just kidding!
[10:34am] GUIs-R-Me: One has 'undo'.... 
[10:35am] merks: Yes, I'd like to get some work done too.  Sadly most of the work I really want to get done happens in the weekends.
[10:35am] GUIs-R-Me: beauty, so we can open one and close the other ?
[10:36am] GUIs-R-Me: tomsontom: drop me a line or just let me know if you want to go over anything...
[10:36am] GUIs-R-Me: I've gotta get back to 3.4
[10:44am] tomsontom: GUIs-R-Me: to really compare them I think I'm ending with 3 x 2 plugins (I only look at the presentationmodel & presentationmodel.workbench project)
[10:44am] tomsontom: 1. presentationmodel & presentationmodel.workbench from Eric
[10:45am] tomsontom: 2, presentationmodel.pure.emf & resentationmodel.pure.emf.workbench (that's where I check that my model holds every thing yours does today)
[10:47am] tomsontom: I will there use generated classes and the generated interfaces
[10:47am] merks: A team project set file we could import would be useful...
[10:47am] merks: Maybe you want to post that on the mailing list when it's ready...
[10:48am] tomsontom: 3. resentationmodel.facaded.emf & presentationmodel.facaded.emf.workbench where EMF is hidden behind a facade
[10:48am] tomsontom: merks: will do
[10:49am] merks: Thanks tom!
[10:57am] benny`work left the chat room. ("Ex-Chat")
[11:02am] GUIs-R-Me: ..and I thank you as well !