I take the opportunity to throw in another 2 cent of mine (giving me an overall share of 4 cent in this thread ;).
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. qooxdoo reputation I'm surprised to hear that RAP and IBM are being the flagship references for qooxdoo. What about 1&1, one of the biggest internet hosters worldwide, and GMX.com, with some *hundreds of thousands* of users using it's qooxdoo-based mail client?! Does anyone care to point prospective customers to our "Real-life Examples" page[1]? qooxdoo contrib contrib has always be seen as an incubator, just read the main page [2]. So there was always the perspective of bringing suitable contribs into the core framework. But who will maintain them? It's not enough to copy the files over. If they are in the framework, it's sort of a commitment to maintain them for the foreseeable future. Who will do that? Who will commit himself for the next 3+ years to maintain some widget or name space in qooxdoo?! If we find it a challenge to add more features, how much more would it be to maintain more foreign code?! qooxdoo user base How important are users for me? Very important! But there a differences between users, and our most important user is, guess what, 1&1. Why is qooxdoo open source? Because 1&1 decided to share generic development done for their purposes with other people who may find it interesting and useful. Do we want to grow our user base indefinitely? Why not? But as it currently stands we're at the brink of what we can handle. Fabian has left the team and it is hard to find a replacement. In-house demands for qooxdoo are growing (and this is a Good Thing). We are spending about 1-8(!) hours per day on the mailing list. People outside the core team that are really effective are rare, and do not stick with the project (like Matt Gregory, who did an excellent job on the ML while he was with it). Do we want more users? I for one want more givers, and not only takers. And without that, I'm quite happy with the user base we have. Most people using qooxdoo are concerned with their own work and projects, and this is all fair enough. Most people even don't care to comment on announcements or weekly status reports as if they simply weren't there. Ok. But all who have demands or desires for anything new or different, should think at the same time that our resources are tight and should offer real contributions (read: code) with any enhancement request and be prepared to sustain this submission for a long time. I'm sorry for anybody being discontent with qooxdoo, for one reason or another. But we cannot cater for everybody. As I said, another 2 cent. Thomas [1] http://qooxdoo.org/community/real_life_examples [2] http://qooxdoo.org/contrib > Hi, > > This thread is a very important for Qooxdoo community. > I would like to ensure that any criticism express here will be taken as > constrictive, we all love Qooxdoo framework. > > My main keyword : "no upfront fees". > > 1. My main concern : Qooxdoo adoption is not wide enough. > It is always a benefit to increase developer base. > Open source project need open source developers, so we need more > developer, not less. > > When we discuss with our customers, Qooxdoo choice is always tricky to > explain as they just never heard about Qooxdoo. > The fact that Qooxdoo is the foundation product or RAP architecture from > IBM is a good point not not enough. > Our customers heard about JQuery, Dojo; Air, Flex, ... but not Qooxdoo. > I think the following point contribute to the fact that Qooxdoo user base > increase too slowly : > > 2. contribs > do not make Eclipse's mistake : lots of wonderful plugins for everything > everywhere. > People get lost when they arrive and this contribute to point 1. > Make things simple first. Later on, if they want, they could digg for > contrib : "no upfront fees". > => the framework you can download must contain all needed elements without > any use of contrib, especially for widgets. > (when you just start Qooxdoo, including a contrib is seen as a complex > task) > > Maybe a process like Apache is a good idea : first contrib are hosted on > incubator and later on as top level project. > a community (not just few 1&1 people) vote and ensure quality of top level > project. > That committee also ensure that there are no dozen of contrib for the same > things. > Things need to be kept organized, it won't be organized by itself. > > 3. initial complexity > I think the Qooxdoo learning curve is too steep. > I already said it, I didn't change my mind. > Qooxdoo build is too complex for first time developer : "no upfront fees". > Give Qooxdoo as an optional big all-in-one file to download. > This is universal, any developer understand that one big file can be > included and then used. > This is not optimal, OK, but this is not a bad news, this is a GOOD news. > Let me explain. > The developer learn Qooxdoo building his apps step by step concentrating > on why he choose Qooxdoo : the javascript framework, the widgets. > No need to install Python, no need to learn and understand config json > file : just a simple file to include. > > Now he has a Qooxdoo apps but not optimized, the good news come : Qooxdoo > has a gift called Qooxdoo build. > It is in Python and can optimize the apps for free ! Isn't that a good > news ? > The developer has to learn the build system only when it need it and not > before. "no upfront fees". > > Of course, the build is still the advised way to use Qooxdoo but let the > developer decide by himself, please do not decide for him that he need or > not that build. > > This will make Qooxdoo simpler to use at first time, and so improve point > 1. > > 4. multimedia and appearance > Default "modern" appearance could have better look. > Eye candy is important. > > I don't think people will be motivated enough to develop their own theme > or some widgets. > Unfortunately, human being will let people choose other framework for bad > reasons : appearance and lack of time. > Contrib is not either an answer (see point 2). > I don't have idea here but I hope we will not dive again in our beloved > API without trying to improve appearance. > > > Conclusion : > Usual warning and disclosures : I do not intend to whine, complain or > other negative things. > I'm just trying to help improving a product I choose as an element of the > software architecture of our product. > We are now highly tight to Qooxdoo. > After more than 5 years following Qooxdoo project and nearly 3 years using > it, I would like to thanks Qooxdoo for letting us building Web GUI without > using nasty tags ;-) > > My 2 cents. > ------------------------------------------------------------------------------ > 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
