- This topic has 8 replies, 7 voices, and was last updated 19 years, 1 month ago by
.
-
Posts
-
It would be nice if there was support for a JSF Component palette such that a developer could drag a control onto a form and then edit it’s properties through a dialog. I’ve seen this in WSAD 512 and thought it was useful.
Ben
OK, I am confused. Have a look at the 2nd and 4th posts by one of your guys, Scott, and please comment.
Actually, to be clear, we’ll have a JSF flow designer, for laying out the flow of your applications, available on all platforms. We’ll also have a JSF WYSIWYG page designer, built on our visual JSP designer, available in 4.0M3 on the Windows platform only.
Actually, our visual JSF designer will be in 4.0, not 5.0. Riyad was just a little quick on the keys this morning. My post on availablility in 4.0M3 is still correct.
Scott, are there any details about the visual JSF designer for Linux and Mac OS X available? Almost all of our developpers work on Linux, one guy works with Mac OS and we currently do not really use Windows for development.
We are really looking forward to the visual JSF designer. I know it has been explained before, but personally I still don’t understand why you have to take the native road when working in Java. Isn’t GEF suitable for this kind of visual editor?
What Windows API are you exactly going to use that isn’t available in Java? Maybe it would be an option if you compiled a version of your plug-in with winelib bindings? (if there are copyrighted DLLs involved, you can ofcourse not ship these along, but there’s a high probability that many Linux users have access to a Windows license since it comes pre-installed with pretty much every PC).
I second you on that point.
I was pretty desapointed to see the UML tools are not available on Mac OS X… If this is the same for the JSF visual editor, I really don’t understand the choice of building on top of a Java stack…I agree with the sentiment of the last post, it’s a little frustrating to see these windows-only features cropping up in MyEclipse, especially for JSF visual design as the framework is really premised on visual design from it’s very foundation. I’m a Linux user as I like to develope in an environment that very closely resembles production. Unfortunately leaving us behind in some of the key features might drive us to start scoping out the competition (sorry, I really do like MyEclipse, but productivity rules the day).
I was pretty desapointed to see the UML tools are not available on Mac OS X…
So were we, but there’s not much we can do until the Eclipse platform team fixes this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384. So, please direct your ire at them on this one. They just don’t support the Mac to the same level they do Linux and Windows.
I know it has been explained before, but personally I still don’t understand why you have to take the native road when working in Java. Isn’t GEF suitable for this kind of visual editor?
GEF would likely be suitable if we wanted to write the entire thing from first principles, and as a result never finish. We made an architectural descision to ride on top of all the embedded browser APIs on the windows platform so we could avoid an extremely large piece of work. While we also considered Mozilla as a base, its APIs were extremely limited to the breadth of features that was available on Windows. So, for this first release it’s Windows only. That doesn’t mean we’ll never support Linux and Mac at some point; it only means we’re not doing it now.
What Windows API are you exactly going to use that isn’t available in Java? Maybe it would be an option if you compiled a version of your plug-in with winelib bindings?
Basically all the IE APIs. I don’t think winelib has implemented any of them, at least based on this email:
http://www.winehq.com/hypermail/wine-devel/2003/07/0358.html
Please note that they quote that Microsoft spent over 1 billion dollars building the browser infrastructure. I think that makes it clear why we didn’t go with a ‘roll our own’ approach. 😉@support-scott wrote:
What Windows API are you exactly going to use that isn’t available in Java? Maybe it would be an option if you compiled a version of your plug-in with winelib bindings?
Basically all the IE APIs. I don’t think winelib has implemented any of them, at least based on this email:
http://www.winehq.com/hypermail/wine-devel/2003/07/0358.htmlI see. Well, I happen to have this old project hanging around ( http://sourceforge.net/projects/jdawn ) that isn’t exactly a visual editor, but builds on IE nevertheless. I haven’t touched the project in ages, but it might be interesting if I can get this to work with winelib. (a quick run with the wine application didn’t worked 🙁 )
Also, it may be worthwhile to just experiment a bit with this yourself. A lot has changed in Wine since 2003 and atleast today IE itself runs pretty well on Linux using wine.
Please note that they quote that Microsoft spent over 1 billion dollars building the browser infrastructure. I think that makes it clear why we didn’t go with a ‘roll our own’ approach. 😉
I understand, although last time I worked with the so-called reusable browser object it was not really -that- reusable. Lots of limitations and an awkward interface, especially if you wanted access to a bare HTML parser (which I needed in my situation).
