Stefan,
my/our situation is similiar to your's, doing applications with Qooxdoo "as
is". Not only for the intranet, but also for (paying) customers. So far,
our customers were mostly concerned about functionality and didn't care much
about theming (as long as their logo is somewhere on the application). Of
course, if theming is a demand, we'd have to spend effort on that, but it
seems doable.
I strongly disagree with the idea of forking, though. This would, I believe,
not help anybody and the fork would certainly loose the support of the core
developers at 1&1. I doubt that anybody currently working with Qooxdoo would
be able to pull that off without loosing quality, vision, and above all
support of the users through the mailing list.
I believe there is room for improvement in various areas. Finding a way to
integrate contribs more closely would be one on my wish list. On the other
hand, that only works if either the contribs are small enough for the
core-team to review and adopt. Or there would have to be a BIG commitment of
the contributors to make their contribs work with future releases of
Qooxdoo. Although I assume that there won't be as big API changes as before
the 1.0 release.
So far I have seen only a view contribs that I'd consider to be close to the
quality of the core framework and we'll have to see how long they stay
usable ...
Cheers,
Fritz
P.S.: BTW, all the "just hire some XYZ guy ... to improve (whatever the
requestor has in mind)" sounds great. The downside is, that even if
money wasn't an issue (and I don't know anything about 1&1's funding
of Qooxdoo), the real problem is finding the right person (fitting
both with technical and social skills). And even if identified, this
person would still have to want to change jobs ...
On Tue, 15 Jun 2010, Stefan Volbers wrote:
Time for me to spend a couple o'cents too...
Unlike many participants in this discussion, I don't use my own
framework on top of qooxdoo, but simply create web applications, 100% of
which are business intranet apps with no demand for sophisticated
appearance and alike.
This job gets done extremely well with qooxdoo as-is. The only thing
which could improve my developer's life would probably be an IDE with
some GUI creator.
One thing I noticed that many of us seem to have in common is that there
are only few HTML authors here, and many of us prefer to not use that
markup language for hypertexts in web applications.
Beniot's words on javascript newbie devs made it clear to me - there's a
lot of people out there who are used to build apps with HTML, and to
make their life easier they soon begin to use libraries to overcome
browser limitations and easen AJAX stuff.
That's not my world, and probably neither yours, dear reader. Using
qooxdoo cannot be compared to using any other javascript library,
because in 99% of cases using qooxdoo means complete abstraction of
HTML/CSS and adopting to a totally different OO-system.
It's been said before that the learning curve of qx is steep, but it is
worth it, at least for anyone doing business web apps for a living like me.
Surely the learning curve doesn't suite if you got two days trying to
implement some database processing by web app, like Rob wrote in this
thread - meaning that qooxdoo *cannot* fit everybody's needs.
So I'd search the reason for qooxdoo's less-than-optimal adoption in
most developers not being able (maybe due to time constraints, or
creating SocialApp V3423.6 with SEO) or even willing to drop HTML/CSS
and concentrating on the different work flow.
If so many of you prefer a single-file library plus more marketing, it
might be time for a spin-off, or fork if you prefer; remember qooxdoo is
LGPL and you are free to do so much of it!
Me, I like qooxdoo as it is, it is *perfect* for self contained RIAs.
Thanks for reading, and again thanks to the core developers: you do a
great job!
Stefan
On 15.06.2010 13:55, benco wrote:
Hi everybody,
Very interesting post indeed. I Think nearly everything has been covered so
I only will make some comments and suggestions.
1) Indeed, Qooxdoo isn't so famous - I didn't say 'powerful' ;-).
Every javascript newbie developer will use Jquery instead because they don't
need the strong widget abstraction. They only will use scripts made by
others (it's so easy for them because they only need to include the files in
their html code and don't need to build an app) or work with the bom
structure because they plan to generate html, not javascript that will
generate/display html.
Maybe a good approach - it's just an idea - would be to create a lot of bom
contribs - like the overused lightboxes effects and so one... So even
newbies/simple bom contrib users would try to use what make qooxdoo so
powerful in the end.
Personally, it's sometimes frustrating for me to be forced to use jquery for
all theses common html/js things (lightboxes, fisheyes and accordion menus)
in the traditional pages but I don't have so much time to spend on refactor
this for qooxdoo. I know it's a bit like "reinvent the wheel" but I'm sure
it could help making Qooxdoo more used by newbies.
2) The contrib repository is a bit like a mess. It would be so nice if there
was some hierarchy or categories...
3) Maybe it would be nice if there was a config builder or a gui for the
compiler. People may take a lot of time first to figure out how it's
working. And sometimes, people are not aware of all this config declaration
variables than can help in the build/source process (like copying, including
files ...)
And another great feature with the config builder would be to have some more
config.json templates than the common ones. For instance, include the forms
elements in a whole package directly ... ?
4) Indeed, the mandatory "rebuild process" is sometimes frustrating.
Personally, I edit sometimes directly the build script file to do simple
things like add a new resource file (and to be honest, sometimes I prefer
directly use the full http path to the resources than using the alias way to
do because I know that it won't force me to rebuild the whole qooxdoo app if
I plan to add other images after the first build)
Voilà, I hope it helps :)
Best,
Benoît.
------------------------------------------------------------------------------
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
--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch
------------------------------------------------------------------------------
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
