Petr, personally, I sympathize with the idea of pre-build qooxdoo packages. But if we published such packages so people could download them and just throw them into their common script folder, how is this supposed to work? The issue of images and other resources of framework classes has to be solved. I don't want people to use things that do not work. jQuery has a much easier job in this regard, as it can be self-contained in a .js file.
T. > Hi Thomas, > > I'd like to react on this: > >> Single-file qooxdoo >> People sympathizing with this idea should also consider handling of >> images. How would a single-file qooxdoo download handle the many images >> that are used by framework classes, from obvious images like icons in >> the >> Tree widget to denote files and folders, to less obvious like the >> background images for buttons (for pressed, unpressed, hovered, ... >> states) and images to create the border decoration of widgets. Can >> anyone >> offer a compelling strategy how to address this? Because if not, the >> whole >> idea is flawed, because as it currently stands you cannot use qooxdoo >> widgets without the accompanying images. > > How others did it? > > Maybe it's time to think about architecture and to build modules > instead of generator+one monolithic file. I think that qooxdoo devs > were really inspired by Java (the filesystem, one class per file, etc) > and did really hard job to allow this kind of programming (generator, > resolving dependent classes, etc), but is this the way other > developers want to do? For example I'm not using this concept, this is > reason I created QxBuild. I want one single qooxdoo library, but if > this library will be divided to sections (Core, Virtual, ... I talked > about) then it will be good. I'm talking about this, because this is > possibility how to use qooxdoo that is not in qooxdoo website, what > about new users coming from other worlds who do not understand how > they should put one class per file and use generator - this is the > point. > > Qooxdoo is based on really monolithic architecture (compiler, theming, > assets, everything must be known at compile time) and there is no way > how to make an add-on (new widget that contains also some custom theme > + resources) without recompiling the whole qooxdoo. I think that this > the is main problem in this area. > > This was my 2 cents ;-) > > I'd like to write more about that, the possibilities I see, etc, but I > need some time (also my English is quite bad) > > Best regards > - Petr > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
