incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FORMER 03 | Robert Brendler <>
Subject Re: [POLL] tag
Date Fri, 05 Oct 2012 15:43:46 GMT
I've been using Flex for a while now and must admint I never really used 
DV, because whenever I opened it, some of my custom components weren't 
displayed right or manipulating an object by mouse destroyed some of my 
percentage widths somewhere in the code, also dragging new components 
into the right container was always a bit fiddly when you got a couple 
of nested containers, I found developing components in separate small 
apps and hack-build-run cycles to be actually faster than searching and 
fixing changes in my code that DV left unnoticed.

Eventually I found it more productive to do the design first e.g. in 
photoshop, then chop it into pieces that I convert to V and HGroups, 
apply some svgs/fxgs from e.g. illustrator and that's it. I never saw 
the point in purchasing and getting used to an extra piece of software 
(namely catalyst), because I am just faster with the other tools.

When comparing this workflow to some other work I have done with 
html-js-css and a proper inspector like firebug there are worlds in 
between. You edit and refresh the browser, or even do life changes, no 
compile needed. Something like resizing components in firebug by up/down 
keys is what you want when playing with fluid components, but did DV 
work like that without messing something up, I don't know, never got 
that far. I imagine coding such functionality from scratch if Adobe does 
not contribute would be quite some effort.

Throwing in some ideas ... please edit or correct if I am bullshitting 
... I would go with the flash wrapper for the ide (e.g. eclipse), but 
only for passing ide specific variables such as project paths and the 
resizing of the wrapped application. Coding the whole layout new in java 
or sth would just be way too much and add a whole new project named 
"mimic the flex layout with java". Also as stated before we are 
targeting flex/flash developers who are more likely to contribute than 
java developers. In order to handle native drop events from other (e.g. 
eclipse) views, it should be an air app that is able to pick them up. 
The design view itself would just be a big empty drop-area. On occurance 
of a drop event from outside, a factory would analyze the drop and 
create an according element and wire it as sub-drop-area automatically. 
This way it would even be a (limited) clickable dummy. Eventually a 
crawler goes over the object tree and returns it formatted as mxml or 
sync it as view model with other detail/property/library views through a 
socket connection. Dropping in custom components would require some 
dynamic library loading of the app. ... etc ... etc ...

I'd really love to contribute, but I suppose neither my employer nor my 
wife will grant me enough time to do so.


On 05.10.2012 02:37, Jonathan Campos wrote:
> On Thu, Oct 4, 2012 at 10:19 AM, Michael Schmalle
> <>wrote:
>> Since my tone was being questioned, how am I as a volunteer supposed to
>> react to a statement like this?
> Sorry if I offended. I wasn't meaning the tone was negative, just didn't
> seem hopeful. I feel that it can be built, it just takes people interested
> in it. I will admit that I don't really miss design view, but that is just
> me.

_____ FORMER 03 GmbH
_____ infanteriestraße 19 haus 6
_____ 80797 muenchen


_____ fon 089.322112.28
_____ fax 089.322112.11

_____ geschäftsführer
_____ sebastian fiedler
_____ gert zellentin

_____ handelsregister
_____ HRB München 148468

_____ steuer
_____ ust.-id DE 229107876

View raw message