Hi, Jim! > So what you are saying is that you feel it is perfectly OK that people > (read > the list posts for the past 2 weeks) have to spend days or weeks trying to > do something simple like change the font or height of a QxListView header?
What I said was that it is not uncommon for developers to reach a somewhat frustrating point in any sufficiently complex software project. Obviously, this is the case, right? Given that qooxdoo is an open source project under heavy development you should not expect too much at the current stage for the newest or most complex features (Table, renderers, etc.). While a lot has already been achieved, it clearly is work in progress. Nothing is deliberately made the way it is just to bug people, though. Some of your requested features are indeed neither trivial to use nor fully implemented yet. Hope the various feedback helps to cope with these issues in the meantime or to go on and improve it. > And that in order to do so, you need to be an expert in the internal > workings of a QxListView? That is the thought process that I can't > understand. If you don't think that needs to be fixed then I am wasting a > lot of peoples time. I repeat myself in inviting you to contribute to this particular part of the development process. Your experience with rapid application development should provide quite some good input. Looking forward to the collaboration, Andreas > On 7/28/06, Andreas Ecker <[EMAIL PROTECTED]> wrote: > >> >> Hi, Jim, >> >> sorry to hear about your current frustration. :-( Hope you get over it >> soon. >> >> While I think it is perfectly ok and quite common to reach low points in >> using any sufficiently complex software project, I do not think your >> assumptions and expectations are appropriate. >> >> Jim Hunter wrote: >> > I am having a hard time subscribing to the thought process that is >> being >> > used to create new controls for qooxdoo. As a 'consumer' of the >> toolkit, >> I >> > should not need to know how each control is put together to use it. The >> > header of the table is a great example. As a consumer/user of the >> table, >> if >> > I want to make the header font Bold, Arial, 18pt, I should not need to >> know >> > that there are different controllers for the header then there are for >> the >> > body or footer. As a consumer, I should only have to get a handle to >> the >> > header via some call like getHeader() then set the font attributes or >> style >> > attributes or whatever. Internally, it is perfectly fine that these >> pieces >> > are controlled by different mechanisms/rendereres etc. That is just >> fine, >> > but access to those pieces should be surfaced to the consumer at the >> table >> > level. Give me an example of any other mainstream language where you >> > need to >> > know everything about the way a control was created in order to use it. >> > If I >> > drop a table on my Delphi form, and I want to set the font color, I >> don't >> > need to dig three levels deep to find the small piece of the code that >> > controls the font in order to make a change, I simply use >> > table.font.color:= clBlue. This is common in all languages. If I was >> > someone that wanted to >> > create a new control and had many sub components to handle different >> > aspects >> > of the control, I would get it all working then create helper functions >> at >> > the top level to allow for easy access to the underlying properties. >> > >> > I guess what I am missing here is why everyone thinks it's better to >> over >> > complicate things instead of making this an easy toolkit to use? The >> bottom >> > line is that users of the toolkit should never need to know as much >> about >> > the toolkit as the people that created it just to do simple things. >> >> You mention the word "customer" quite often, also "any other mainstream >> language" and especially "Delphi". Well, qooxdoo is not to compete >> against a commercial rapid application development environment like >> "Borland Delphi", which has been perfected over 20 years by a major >> software company. >> >> qooxdoo is an ambitious LGPL-licensed Open Source project, that aims at >> taking JavaScript web development to the next level. It is work in >> progress involving many developers and users. If anyone thinks something >> needs fixing or improvement, he/she can just do so. It is Open Source, >> right? Who says that we cannot make any existing stuff better, faster, >> easier to use? >> >> I'd like you to continue to contribute by either rethinking or recoding >> existing features (e.g. >> http://bugzilla.qooxdoo.org/show_bug.cgi?id=116) or by even developing >> any new features. Your knowlegde and experience of Delphi will >> certainly be a source of inspiration. >> >> Cheers, >> >> Andreas >> >> PS: Someone once said: "As a decade old delphi lover, i would say >> qooxdoo is like VCL for javascript. :)". ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
