Hi Varol,
I agree 100% with you. I tried to point out issues I have with generator,
and in general, with the monolithic architecture, but I just get used to
accept that this will probably never change. My first qooxdoo project was
based on plugins loaded dynamically, and this is the reason I started
qxbuild (maybe it can be still found, don't really maintain in). Basically
I faced this difficulty from the beginning and everything I did was just
workarounds.
I think there are probably more issues that complicate contribs and fast
adoption:
1. Monolithic architecture (already wrote about it).
2. Theming - try to create a new theme - you have to write thousands of
lines, it's work for days to create a nice one. I'm also not sure if
theming supports all new CSS features, for example `outlines` are powerful
for styling widgets, should be also used by table width.
3. Contrib Theming - this is hell as a contrib can use some theme you have
to use to use the contrib. Try to use two contribs that inherit a theme.
4. Table - Nobody really touched this component for years, for me table was
one the best components in Qooxdoo.
5. Databinding - I didn't find the databinding and data marshaling qooxdoo
does useful.
These just came on my mind.
BTW I'm still maintaining one qooxdoo app, but I don't know if I would
start using qooxdoo in a new project - web is not IE6 anymore. Anyway I'm a
qooxdoo fan and I would love to see qooxdoo growing, however, I would not
contribute if the project stays as is and doesn't innovate, especially in
areas I pointed out.
Cheers,
Petr
On Mon, Oct 13, 2014 at 2:33 PM, Varol Okan <mym...@movingsatellites.com>
wrote:
> 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
>
------------------------------------------------------------------------------
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
