+0
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.
Cheers,
Rob
On 05.10.2012 02:37, Jonathan Campos wrote:
On Thu, Oct 4, 2012 at 10:19 AM, Michael Schmalle
<apa...@teotigraphix.com>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
_____ robert.brend...@former03.de
_____ www.former03.de
_____ 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
