I think in general QooxDoo is a great framework to work with. 1) Workflow For me one of the biggest drawbacks has always been the enforcement to the java-like file structure and the compilation per app.
Since I am using it more like a complete solution and load apps on demand I have been able to work around this by making changes which allow me to load in the complete qooxdoo library iat start time, and then load apps dynamically. I think for RIAs this is more common IMHO, as a complete page reload is not that common anymore. Also looking at the compiled size of a small app in its current form will be almost the same size than the complete qx library ( 2MB ). As a side note: QooxDoo 0.7 was about 1MB. However this 2MB also contains now the mobile widgets which I could have carved out. Thing is that I am not too concerned. All things considered 2MB is about the size of two jpgs. So to sum up my recommendation would be to have a core lib, which can then load plugins. This is how other frameworks are usually doing it. core == server + loader ui = Desktop mobile = mobile web = web If this would work, then contribs would be able to be used as cut'n paste to existing projects and you would not have to 'integrate' the contrib samples. They would ( or should ) simply work through E.g. qx.loadScript ( "filedialog.js" ); without the need to recompile all code integrated into one app. Then you could rally the community around writing additional plugins. 2) Server know-how Ever realized that compilation requires knowledge of Linux/Windows Cygwin etc ? I have no issues with this. In fact most power users will not have any issues with it. Problem is most web developers are not versed in BE tasks and the compilation step over-complicates using QooxDoo for them. So they switch to a plugin based system where they can focus on developing in FireBug and the only BE interaction they have is <scrip src="abc.js" /> So offering them qx.js, and qx.min.js is what most web developers would expect to deal with rather then "./generate.py source-hybrid" and ./generate.py "build"; scp user@server:/path/to/web/ I'd say you provide both options and check the download stats after a while, after all, I may be wrong ;) 3) API stability Guys QooxDoo is great but the API is changing way too much, even in between minor versions. This must be addressed in some way. I am not suggesting to keep all API calls backwards compatible for eternity but unless you can promise a company stability they won't touch it because the TCO is too high to maintain a app using QooxDoo. There are so many great QooxDoo projects out there which break after a few months. I like to compare Qx with Qt in some way Qt has changed dramatically over the years but the API in major releases were pretty stable for the most part and you could count on it to write your app. BTW anyone here remembers QxButton instead of qx.ui.form.Button ... :) Cheers, Varol :) On 10/10/2014 08:43 AM, d...@cost-savers.net wrote: > Hi Martin, > > This is the first time... > ...where you show a little humbleness. > ...when you ask deliberately for help. > ...you show your understanding that you can not beat the world yourself alone. > > but why did it take so long? This is all good that you have come to this > conclusion though... > > It is all history now, so let us focus on future. > > I would like to see a clear specification where you see the community can > help qooxdoo, not the qooxdoo team because all contributors will be, to take > a lead position among the frameworks. > > With joined forces maybe maybe maybe it is not too late for qooxdoo...;-( > > Best, > Stefan > >> Hey, >> >> finally I have the time to get back to such a important topic, event if the >> last mail in this thread has been some time ago. First of all, the feedback >> of all of you shows me that you all care about that topic which is a really >> good point. >> >> I think I have heard on thing in all the discussions: the current system is >> not good enough but I think before talking about solutions and why one >> solution is better than the other, we should focus on the flaws that the >> current system has. >> >> Christian did a good job in his initial post be summing up some of the flaws >> and I agree on most of the points. Especially the need to update the >> checksum is too cumbersome to do it each time. There is already a bug report >> about that [1] which needs to be fixed. But that hasn’t been done up until >> now which brings me to a good point Petr mentioned in a post: >> >> The problem I see is that qooxdoo tries to be for everything, which is >> simply impossible to achieve for the current dev-team. >> This is one of the main problems we currently face. The whole code base grew >> over the last almost 10 years and is now quite huge. This includes a lot of >> maintenance which is why the dev speed decreased in the last couple of years. >> >> Additionally, I want to quote John: >> q/qxweb is not compatible with any nice UI widgets, so for “thin” front end >> I use requirejs, jquery, knockoutjs, etc … and a home made qx.Class. I >> agree that Qooxdoo is not really suitable for that kind of development, but >> mostly because the qxweb provides very little compared to what is already >> out there and more established. >> I agree with John here and this is what concerns me most. Just take a look >> at the JavaScript frameworks popular nowadays like ember or angular. There >> is less what they have in common with qooxdoo. We also monitor the download >> stats and this is decreasing as well. >> So in my opinion, the framework needs to do big steps in the future to get >> it back to a level where we can compete with other frameworks. And the >> contrib system is one of these steps but you will all agree, that this does >> not need to be one of the first steps. A good conritib system is worthless >> without contributions. Which brings me to a thing Christian wrote: >> I'm also very much in favour of using an existing package manager. >> I agree with that but not only for package managers. The open source >> community evolved and a lot of cool stuff has been created and built within >> the last couple of years and we haven’t been able to get any benefit out of >> that because we do have a lot of custom approaches. With bower e.g. twitter >> implemented a contrib system for all of web development but we could not >> participate of that because we have another way of integrating dependencies. >> We see such things all day as soon as something cool and new comes up we >> usually can’t use it out of the box. >> >> To cut a long story short, we currently focus on getting the framework to >> the next level and we don’t have the manpower to get all done you suggested. >> But as this is in the end a open source project, we would be happy if >> someone want to take care of that. Of course we would be available for >> discussions and for some help but most of the stuff could be done by the >> community as you know you needs best. One of the first and most obvious >> tasks would be to get rid of the checksum for master versions in the contrib >> catalog. A pull request for that topic would be highly appreciated. >> Another quick win could be commit rights for the contrib catalog in order to >> circumvent pull requests. Just send us a note so we can add you as committer. >> >> Regards, >> Martin >> >> >> >> [1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=8524 >> >> Am 10.09.2014 um 16:45 schrieb Dietrich Streifert >> <dietrich.streif...@googlemail.com<mailto:dietrich.streif...@googlemail.com>>: >> >> Hello everybody, >> >> I've tried to follow the discussion and I have to say that I'm just lost >> on all those possible options, implementations and versioning stuff. >> >> I've just did a few JSDoc corrections do UploadWidget on sourceforge [1] >> via svn which where reported in an issue at bugzilla from Christian >> Boulanger. >> >> I'm currently using 3 contributions in my project, the aristo theme by >> John Spackman, SmartTableModel by Derrell Lipman and of course >> UploadWidget by Tobi Oettiker, Petr Kobalicek and me. >> >> My "strategy" is to use manually checked out contributions to local >> directories with manual references in the config.json file via the >> libraries key. Til now my source was sourceforge. >> >> Now I've seen that there is an (from my point of view) outdated >> uploadwidget contrib on github [2] where Derrell already has made those >> changes which I've made today :-( >> >> I suspect that the github version and the sf version already evolved to >> subtle differences. That's odd. >> >> Regards >> Dietrich >> >> [1] >> https://svn.code.sf.net/p/qooxdoo-contrib/code/trunk/qooxdoo-contrib/UploadWidget >> [2] https://github.com/qooxdoo-contrib/uploadwidget >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> _______________________________________________ >> qooxdoo-devel mailing list >> qooxdoo-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > >> _______________________________________________ >> qooxdoo-devel mailing list >> qooxdoo-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
