Kevin,
You just made the argument for XSWT. :-) Because XSWT adds 0 layers of abstraction between itself and Java, it's literally just a 1:1 mapping from a more convenient, less verbose notation. -Dave Orme On Nov 5, 2008 5:32 PM, "Kevin McGuire" <[EMAIL PROTECTED]> wrote: Great discussion guys. I'm only beginning to understand this area and the thread has been helpful. Actually my hope for the roundup is exactly this kind of shared understanding of the technology, and some common view of the goal. > The UI model tries to abstract > away the underlying technology by focusing on what information ... Hallvard, I admit that I know nothing of your research so I'm just going to speak quite generally, which may not at all match what you're doing: I find this theoretically cool but with my practical hat on I'm trying to understand the benefit this added abstraction buys us in Eclipse. My original thinking was that the declarative language should map 1:1 to SWT, because its SWT that actually does, well, the useful stuff. The buck stops there. Either you can have list of strings, or a list of rendered strings plus images, or owner draw ... its in the capabilities of the widget and the only way to get stuff on the screen. In fact one can regard SWT as this exact toolkit independent model (if we think toolkit=platform) because it attempts to isolate you from platform specifics, thus the SWT list widget is already that abstraction of the concept of a list widget across all platforms. It just happens to be API based, not declarative. My concern is that inevitably when you go to an abstraction, you inherently lose some fidelity. Maybe some capability of a particular system you care about (in this case, SWT) can't be expressed because your model is a common subset. Or, the model is a superset, in which case you write in the hopes of something happening which doesn't on your particular platform. We often see the former case and sometimes the latter in SWT. Since I've already lost fidelity in SWT vs. the platform, I'm hesitant at losing more through another abstraction. Yves, I have a similar concern around the use of XAML since I may lose fidelity in going to SWT, but that's perhaps more a statement of my ignorance of XAML. Thus my thinking was perhaps along the lines Tom outlined: a declarative model written against SWT, exposing accurately the capabilities of SWT but in a serializeable format instead of Java code, providing a model which facilitates mapping to other declarative models. So I question, why do I need yet another abstraction? I guess it would let me go to Swing, which personally I'm not interested in. Maybe it would allow me to go the web, but SWT is going to do what it always does and treat it as a platform. Unless you believe there is an inherent flaw in doing so which a common abstract model solves? I suppose it could allow me to reuse parts of UIs (e.g. some pre-canned wizard pages), but in my experience you always roll a UI that is specific to a problem area. Finally, it allows me to escape a particular programming language, (Java, yeah!) but I think I get that from the declarative aspect, not the common abstraction. What am I missing here? > The main problem with going through XML and a renderer, is that it only handles > the creation p... <naiveQuestion>Isn't this solved to a great degree through the use of databinding?</naiveQuestion> Regards, Kevin *Hallvard Trætteberg <[EMAIL PROTECTED]>* Sent by: [EMAIL PROTECTED] 11/05/2008 09:00 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup? Tom and others, Just a bit of background: My research field is model-based UI design and the last... _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
