Very cool! :)  BTW, does the Eclipse plug-in work with vim plug-ins
available out there?  I haven't used Eclipse (Java was very buggy on
FreeBSD amd64 until only recently), but I'm open to using it if I can
configure it to have a vim-like keyboard mapping.


[ simon.cpu ]




mt1 wrote:
> Luckily, Spket IDE has just released.
> It has not visual design tool, but it is good to work both stand alone 
> IDE and  Eclipse plugin.
> You can select it on your environment.
> I have tried it just now, it works fine. If i can say more, it was good 
> to have more components on the snippets. :p
> 
> mt1
> 
> 
> Cortlandt Winters wrote:
>> HI Andy,
>>
>> I'd like to know. Are you more in need of layout, image design, or 
>> animation design?
>>
>> I'm asking because I have a lot of ideas for the three and have a 
>> theory that layout and animation design would be folk's top 
>> priorities, in that sequence, with image design a lesser priority, as 
>> individual images would probably still be authored in swf or png or 
>> gif and that the top two use cases would be 1) layout/binding and 2) 
>> animation.
>>
>> Does that fit with what you are thinking?
>>
>> -Cort
>>
>> On 4/3/07, *Andrew Chandler* <[EMAIL PROTECTED] 
>> <mailto:[EMAIL PROTECTED]>> wrote:
>>
>>     I don't know about anyone else but we've been using OpenLaszlo for
>>     18 months and we are now in the process of moving away from it to
>>     plain ajax/jsf infrastructure.   The reason given by management is
>>     the lack of visual design tools.   The opinion (and I have to
>>     agree) is that it takes too long to train the new engineers on the
>>     specifics of laszlo design / layout on top of everything else they
>>     have to learn about our product.   Too many of the other tools out
>>     there are allowing you to visually tweak the layout and look and
>>     feel of UI and laszlo is unfortunately behind the times with
>>     regard to this functionality.
>>      
>>      
>>
>>     ------------------------------------------------------------------------
>>     *From:* [EMAIL PROTECTED]
>>     <mailto:[EMAIL PROTECTED]>
>>     [mailto:[EMAIL PROTECTED]
>>     <mailto:[EMAIL PROTECTED]>] *On Behalf Of *mt1
>>     *Sent:* Tuesday, April 03, 2007 7:12 AM
>>     *To:* laszlo-user
>>     *Subject:* Re: [Laszlo-user] IDE4Laszlo status
>>
>>     David,
>>
>>      I know what your opinion on the IDE of OpenLaszlo.
>>      Yes, i agree with you about what you said there are a lot of good
>>     XML editors and OpenLaszlo
>>     programers can use them.
>>       Until a few month ago, i also used Eclipse with IDE4Laszlo.
>>      But now, i am using simple text editor to edit coding, and i am
>>     satisfied with using it.
>>      It was too heavy for my PC that was working Eclipse, Tomcat with
>>     LPS and PostgresSQL for database.
>>
>>      But in the other hand, many engineers are using Eclipse.
>>      I fond a result of using IDE research by Nikkei-BP in Japan, as
>>     following.
>>
>>      http://itpro.nikkeibp.co.jp/article/OPINION/20070329/266887/
>>     <http://itpro.nikkeibp.co.jp/article/OPINION/20070329/266887/>
>>
>>       Unfortunately it described with Japanese, but i say simply,
>>     Visual studio is the most used and
>>     Eclipse is the second.  From this research, we don't look out the
>>     Eclipse environment.
>>      
>>      We should mention who are use the IDE.
>>      You know OpenLaszlo provided IDE for Eclipse at the first, but in
>>     Flex, the first was the FlexBuilder,
>>     the second was for Eclipse. I think we should give attention the
>>     IDE for whom.
>>      If we have image for *power* engineers, we don't any take care
>>     about IDE, because they can find some
>>     good programing tool which they like.
>>      If we have image for *ordinary* engineers, we might to provide
>>     for Eclipse environment. Because most
>>     of the engineers are in a IT department in their company and they
>>     can hardly to choice their
>>     *environment* for their development. The reason why, the one is
>>     the issue of standardization and the another is the
>>     *custom* for their coding style, and there are many more, i guess.
>>     Just i can say, there are
>>     many barrier to introduce some *new developing tool* into their
>>     corporate department. But if it is based on
>>     Eclipse, it can easy to introduce into it. Because they already
>>     *have* and *know* it.
>>      But if we have image for *beginner* engineer, that mean who is a
>>     web designer or a novice programer,
>>     the visual design tool will be big present for them.
>>      I know you are almost thinking about those.
>>
>>      Back to your opinion, the visual tool is great efficient tool.
>>     But it should have relation with the text coding tool
>>     or it ought to include it. Because it must occur with bit control
>>     on the editor, like x/y position control or some
>>     attribute and more.
>>       I can say it dose not work on Eclipse, but Eclipse plugin have a
>>     advantage compare with it.
>>       It mean not *tool* but *strategy*.
>>       OpenLaslzo and Webtop are very cool, but most of engineers
>>     requires a development tool too.
>>       I have no doubt it is very important point to generalize
>>     OpenLaszlo.
>>
>>      So my opinion, it is glad for them to get two coding tool. The
>>     one is the *special* design tool( like FlexBuilder )
>>     and the other is the plugin for Eclipse. :-)
>>
>>      mt1
>>      
>>
>>     jamesr wrote:
>>>
>>>     On Mar 24, 2007, at 12:16 PM, David Temkin wrote:
>>>
>>>>     mt1,
>>>>
>>>>     IDE4Laszlo -- we (Laszlo Systems) haven't done anything with it
>>>>     and  don't plan to. Doesn't mean someone else can't do something
>>>>     with it.
>>>>
>>>>     One idea that we're discussing now is to kick off a project to
>>>>     make  an LZX-based graphical editor. It's scope would be limited
>>>>     to the  graphical layout, positioning, linkage, attributes, etc
>>>>     of LZX  objects. It would not be code editing-focused -- there
>>>>     are tons of  tools for that. It would be written in LZX, and
>>>>     would run in the  browser. It would support "round-trip"
>>>>     editing, so that you could  edit with an IDE/code editor, and
>>>>     then the visual editor, and then  the code editor again, without
>>>>     loss. The back-end, which would read  and manipulate the LZX
>>>>     files, would be written in Java, and would  run in the same
>>>>     context as OL itself.
>>>>
>>>>     What do you think of this approach? Right now it's just a concept.
>>>>
>>>>     - D.
>>>>
>>>
>>>     I did thought experiments and prototyped a system like this bit
>>>     back.  It is doable, with a set of limitations as to what can be
>>>     edited. You  couldn't see the effects of editing Javascript in
>>>     the IDE (you'd have  to compile because eval isn't strong in
>>>     there) but you could see the  effects of adding and removing
>>>     attributes, changing layouts, etc. To  me the concept hinged on
>>>     building components - classes with  specifications that could be
>>>     read by the IDE - that would become  available to use. It
>>>     wouldn't just be any set of LZX code, but an  easily extendable
>>>     ever growing list of "prepared" classes. This way  the parameters
>>>     to any class could be known and displayed properly.
>>>
>>>     I saw something similar to RealBasic's IDE coming out of this
>>>     approach.
>>>
>>>     I had this running in Blooms  (a laszlo templating system) and 
>>>     although i wasn't targetting reading from LZX - it was going to 
>>>     choose a Blooms language intermediate that would render to LZX -
>>>     I  had some interesting ideas as to how the layout of the IDE
>>>     would  work. For instance, since the blooms thing has "server"
>>>     transforms  that build XML datasources, datasources would also be
>>>     included in the  IDE in a "cloud" that you'd pair and move around
>>>     in groups of their  functionality (in python fwiw). From a visual
>>>     standpoint, i thought  it would be nice to describe complete
>>>     applications with server side  resources in a single environment.
>>>
>>>     The proof of concept system properly read in the list of
>>>     components  and their attributes, and allowed you to make new
>>>     components on  screen, to prove it was possible. It seems so.
>>>
>>>     Hope this is topical,
>>>         James.
>>>
>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 


-- 
And /usr/games/fortune futurama says:

 Leela: Zoidberg!
 Zoidberg: Sorry, you must have been boring.

Reply via email to