Priorities
Dan Brajkovic
reply with a list of the top 5 or top 10 or top whatever issues/
features that you feel would help make Cappuccino better than it is
today and better than all the alternatives out there!
Briam Rodriguez
2. Working examples
Everything else just flows from that.
Mike Fellows
especially IE.
Aparajita Fishman
Which versions of IE? I can't see much effort being put into anything less than IE8.
Regards,
Aparajita
www.aparajitaworld.com
"If you dare to fail, you are bound to succeed."
- Sri Chinmoy | www.srichinmoy.org
Randy Luecke
work extremely well on. The limiting factor with IE is simply speed
and feature set. IE in general is just very slow. There is only so
much we can do. Every new line of code we add will make IE that much
slower.
Mike Fellows
of IE. So any version would be better than none. IE8 onward for
serious work is probably a good baseline.
I've made simple apps work on IE6 and 7 and they just don't have the
javascript horsepower to work reasonably under any circumstance (and IE6
image transparency stuff would be crazy to try to fix and maintain).
Mike
Aparajita Fishman
Noted. Are you a regular IE user yourself?
Mike Fellows
share - depending on whose statistics you are looking at. So if we are
serious about one of the key selling points of a web application
framework, cross browser support, we would be developing and testing
using IE along with all the other browsers. And fixing those little
details that are fixable (for example key equivalents are currently
broken in IE) - and identifying features that will never work well
(scrollview's scroll painfully slowly in a lot of circumstances -
perhaps not fixable?).
I think your point that there is a limit to what can be done with some
of IE's problem areas is a good one. But we don't seem to make any
serious effort to sort out which ones are truly unfixable, and which
ones are just IE specific bugs that will require workarounds.
I'm just suggesting that it should be more of a priority - and yes I
understand that it is a pain in the neck to develop with IE as I've had
to do a fair amount of it for my work.
Mike
Mike Fellows
On 11-09-09 11:02 AM, Aparajita Fishman wrote:
>> As far as I can tell not much testing/development is done on any
>> version of IE. So any version would be better than none. IE8
>> onward for serious work is probably a good baseline.
>
> Noted. Are you a regular IE user yourself?
Only for development purposes. But plenty of my customers are IE users.
Mike
Aparajita Fishman
Of course I agree, but there is more than one IE, and the majority of IE's internet (vs. intranet) market share is IE8+. Limiting Cappuccino to >= IE8 makes a huge difference in the amount of resources necessary.
alosii
IE is sadly still a reality in some "corporate" giants. I'm having a
hard time getting it running acceptably. Perhaps a feature that will
let you turn off transparencies and shadows? I don't know if this will
actually have an impact or IE7 just sucks :-/
On Sep 9, 1:39 pm, Aparajita Fishman <aparaj...@aparajitaworld.com>
wrote:
Aparajita Fishman
> IE is sadly still a reality in some "corporate" giants.
I think "tragic" is a better word for it. But look on the bright side -- at least it doesn't have to work on IE6! :-)
> I'm having a
> hard time getting it running acceptably.
> I don't know if this will
> actually have an impact or IE7 just sucks :-/
IE7 just sucks unfortunately. Its Javascript engine is just too slow. Right now your only hope is google Chrome Frame.
In the future I think we will have to state openly that only IE8+ is supported, this is the second time in a few weeks that someone has gotten towards the end of a project only to discover that it won't work acceptably on IE6/7.
It remains to be seen how much Objective-J 2.0 will improve the situation, but you should not wait for that, there is currently no target date for its release.
Joe Hoyle
--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J Development List" group.
To post to this group, send email to objecti...@googlegroups.com.
To unsubscribe from this group, send email to objectivej-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/objectivej-dev?hl=en.
Ross Boucher
Aparajita Fishman
That depends on what version of IE you talking about and what you mean by "support".
If you are talking about IE < 8, then honestly it is supported only in the sense that a Cappuccino app will run. But it is not supported in the sense that anything but a trivial Cappuccino app will run fast enough to be usable.
Real-world users who have staked their reputation on Cappuccino are telling us over and over again that Cappuccino's performance is not acceptable -- and thus Cappuccino is not usable -- in IE6/7. And if we don't say that up front and honestly, people who depend on *usable* IE6/7 support may not find out until it's too late that such support doesn't exist, which may have serious negative consequences on their careers. That just isn't fair to our users.
Until we have a proven solution to this *in hand*, we cannot in good conscience continue to say that IE6/7 are supported for anything but trivial applications; the facts just don't support it. And no matter what *may* be possible theoretically with better Cappuccino technology, until that technology is being worked on actively, is realistically close to completion, and has proven to solve the problem, we have to deal with the reality we have right now.
Aparajita Fishman
In the not-too-distant future hopefully we can formally put this question to the community. If you look at IE internet market share, IE8 has the largest share right now, so I think we should try to support it.
When it comes to intranet market share, IE6/7 probably predominate, but they are missing out on all modern web technologies, not just Cappuccino, so what can we do...
Randy Luecke
if we had a 100% consensus it's unlikely it would happen until someone
steps up and does it. It doesn't help that we're all Mac users, and it
also doesn't help that no one on the core team is targeting a market
where IE isn't important.
Until someone needs IE support and works on it themselves, it's
unlikely it will happen.
On Sep 10, 3:12 pm, Aparajita Fishman <aparaj...@aparajitaworld.com>
wrote:
Ben Langfeld
Ross Boucher
Obviously 280 Slides is using an older version of Cappuccino, but in so much as it might get slower if upgraded, that seems like an issue worth working on in Cappuccino. To whatever extend we may have spent personal time making the 280 Slides application level code faster in IE, perhaps that's also a reasonable requirement for someone writing any app and trying to target older machines or browsers.
Obviously, no matter what we do, you can still write a slow application using Cappuccino.
Aparajita Fishman
280 Slides is unfortunately not a representative example. First of all, knowing the implementation of the framework allows you to make a lot of unconscious design decisions based on performance. Second of all, a lot of people are making applications that have significantly more complex UIs with CPTableView, multiple splitviews, etc.
> Obviously, no matter what we do, you can still write a slow application using Cappuccino.
Well, people tend to make their interfaces much more cluttered than perhaps they should be. And since Cappuccino is running within a single platform window, the temptation is to cram as much as possible into that one window. This leads to extremely complex screens and slow performance.
Klaas Pieter Annema
- Klaas Pieter
Nigel Goodship
The performance of Cappuccino apps is much slower than it used to be,
even on the current versions of WebKit based browsers. I appreciate
that adding functionality leads to more complexity and hence can lead
to reduced performance, but even basic window redrawing is now very
slow compared with how it used to be. Just trying to resize a browser
window running the GitHub Issues app shows this
(githubissues.heroku.com). The resizing and redrawing is very clunky
whereas it used to be pretty much instantaneous and totally fluid, and
I would guess that the app code hasn't changed much to cause this.
I'm not sure exactly when the performance degraded so much and I can't
say I noticed whether it was a sudden or gradual change, but I would
be very happy indeed if there's anything that be can done to restore
some of the lost performance.
As for the IE issue, many of our customers are still on IE6 or IE7,
but now that Google Chrome Frame can be installed without
administrator privileges, we see that as a viable solution.
On Sep 12, 12:03 am, Aparajita Fishman <aparaj...@aparajitaworld.com>
wrote:
Randy Luecke
There's really not much we can do about it since we rely on the
resizing events.
Aparajita Fishman
> There's really not much we can do about it since we rely on the
> resizing events.
What did Safari change with resize events that killed performance? Is it just Safari or all WebKit browsers such as Chrome?
Dan Brajkovic
Randy Luecke
Webkit proper that made it into chrome.
It either has to do with the frequency at which the resize events are
sent, or how often the DOM is updated during a window resize.
Aparajita Fishman
> Webkit proper that made it into chrome.
>
> It either has to do with the frequency at which the resize events are
> sent, or how often the DOM is updated during a window resize.
We should be able to use the profiling tools in WebKit to figure out where the performance bottleneck is.
Alexander Ljungberg
https://github.com/cappuccino/cappuccino/issues/1325
Alexander
Aparajita Fishman
> There's really not much we can do about it since we rely on the
> resizing events.
I would like to point out that it has *nothing* to do with Cappuccino and *nothing* to do with JavaScript. I loaded a file which had nothing more than this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<title>Test</title>
</head>
<body>
Hello.
</body>
</html>
Resizing is *horribly* slow -- 1 second behind the mouse. Chrome 14 beta does *not* share this problem at all.