Re: Questions about netwindows, probably a faq

On Wed, Apr 07, 2004 at 07:29:44AM -0700, Alex Russell wrote:
> Our intent is to provide the tools one needs to build web apps that 
> give the user better interaction, lower interface latency, and higher 
> usability while keeping the advantages of developing as a web app in 
> the first place. This means that we aren't going to go ahead and give 
> you objects that do every little thing (the DOM already does most of 
> that for us), but we WILL give you objects and widgets that the 
> browser doesn't intrinisically provide, as well as a straightforward 
> way to build your own custom widgets if/when you need to.
> 

	Right, and that's cool. But a novice DOM user like me is is
completely daunted by using DOM: I don't know which parts of it work in
which browsers, which parts work correctly, and which parts are implemented
but require hacks to make them work uniformly across all DOM "compliant"
browsers. I have a copy of the O'Reilly "Dynamic HTML" book. It's an insane
monster of a book, weighing in at 1400 pages.

	Said book documents in great detail which browser supports which
functions and how. But I don't _want_ to have to read this monster, or
even consult it. What I want is _one_ place I can go to implement my
application. So if that means the toolkit "reimplements" some of the things
that actually _are_ cross platform, that's fine by me, especially because
in the next release of browser X they're going to screw it up.

	I hear the point about latency and bloat, but for the parts the
browsers do correctly and uniformly the calls would just be shims - not
much overhead and very little space increase. If even that seems like
a waste of time and space, how about sticking it in an external lib that 
can be optionally included? Maybe I could work on the reimplemented wheel
myself. Really though "reimplementation" isn't really the right word, because
I'm not actually doing any reimplementation, just unification.

	With that done, I know I can go right to the netwindows docs to
implement my entire application, given a few "Hello world" sort of
examples. No muss, no fuss.

> Now, as to your point about the browser not being able to do 
> everything, it hasn't stopped people from trying. Isomorphic, domAPI, 
> and dynAPI in particular have taken the full re-implementation route 
> and built everything up from "canvas" ojects. I have explicitly 
> avoided this kind of re-work as I don't think it's really valuable. 

	Ok, I wasn't familiar with those, but I've spent a couple hours
checking them out. dynAPI seems more concerned with layering than widgets.
Isomorphic seems fairly bloated. domAPI seems to be a little closer, but
neither it nor Isomorphic are open source.

> What benefit do I get by ensuring that my toolkit can't take 
> advantage of improvements in browser rendering, etc...? I guess at 
> the end of the day, there's a difference in philosophy if toolkit 
> design. Whereas some of the other toolkits I mentioned attempt to get 
> everything to be pixel-perfect all the time, NW takes a more web-ish 
> approach to DHTML widgets. That might be what you're looking for, it 
> might not be. You have choices, though.
> 

	I agree.. definitely want to take advantage of the smarts the
browser has already. That's the whole point - I want a unified and consistent
interface to the smarts, which is what the dom standards are supposed to give
you, but don't due to implementation differences.

	On top of that, I want a base set of application widgets as one
would find in application toolkits, most of which are already there, and many
more implemented by netwindows. Then I can get to work on doing real work and
not care about implementation details.

> > 	So that's _my_ goal: to replicate a base set of widgets in a
> > consistent manner to form a gui application toolkit, not just a
> > clever set of handy widgets as some of the other libs seem to
> > offer. I don't care about handy widgets, I care about extensible
> > base widgets - handy widgets will flow from those.
> 
> We aren't the only ones thinking this way about what the browser can 
> do, but it's still rare. It doesn't help that DHTML has been 
> pigeonholed and that most DHTML toolkit development has ceased.
> 

	I suspect it's been pigeonholed for the reasons noted above: eveyone
is stuck trying to figure out how to use it and make it work cross platform.
	Additionally they don't have any sort of "metaphor" with which they
can understand how to use it. People understand GUI apps, and they understand
web pages, but without help they won't get web applications.

> > 	Netwindows seems like it's mostly there, but there doesn't seem to
> > be the explicit goal of supporting a specific toolkit's set of
> > widgets - or did I miss it? 
> 
> I have no intent to look at some other toolkit and say "oh, we need X 
> to become workable as a replacement for Y". Re-doing QT in the 
> browser or GTK, or AWT/SWING doesn't make any sense to me. There 
> might be some room for that when we get to an SVG port of the 
> toolkit, but I have my doubts. We need a browser-centric toolkit, and 
> that's what NW is trying to provide.
> 
	Yeah, with you 100%: I meant conceptually, not providing and actual
QT API. In some instances you've actually done some of what I meant -
such as the tabbed window pane.

> Other toolkits require these because they don't have an environment 
> that already gives these to them. DHTML, OTOH, exists in an 
> environment that already has a box and bounding model, a reflowable 
> set of containers, and a table implementation that can be used to 
> emulate most of these constructs.

	Right, so implementing things like 'pack' and 'place' isn't needed
at all. That makes sense to me now.
	As far as the table implementation emulating the constructs, that
makes sense too, but how to go from GUI frame widgets to table cells requires
a bit of a learning curve. Maybe we could provide a few examples (again,
something I would take on).

> Things like our split-pane widget 
> help to fill in the gap where these don't automatically give you what 
> you need, but we're not going to re-do a lot of work that browsers 
> are designed to handle. That said, I've been thinking lately of doing 
> a cross-browser xul-ish <box> thing. The building blocks are there on 
> most of our target platforms.
> 

	Ok.. my understanding is obviously more of gui toolkit and little
of dhtml. In the gui toolkit realm, you would take a frame, stuff two
subframes into it, then populate the frame with some sort of text widget.
	It _looks like_ you could do this with tables too.. so why is
the split pane widget handy?

> > I suspect that wasn't part
> > of the original goal since typically formatting is done in html
> > itself, but it would be important for an application toolkit.
> 
> Well, that depends. You already have programatic control over HTML, I 
> see no need to give that additional syntactic sugar that just 
> increases the size of the toolkit. We assume our heavy users are DOM 
> clued, because otherwise you wouldn't be successful in building an 
> app in the browser anyway.
> 

	Ok, that makes sense. I would hope to make it so simpler applications
wouldn't require so much dom clue, though. Conceptually people will have
to understand what they're working with, but hopefully some of the lower
level implementation details could be hidden for most apps - sort of like
working with C++ (or other high level language) instead of assembly.


> > 	Anyway, I can't tell if that's either a really obvious idea and
> > basically what you're up to, or if it's just crazy and not close at
> > all, but it _sounds_ cool. If we could do it and have performance
> > not suck too horribly people would beat down our doors to get it.
> >
> > 	Seriously, is that nuts?
> 
> No, but I think that if you bend your world view a little bit, you'll 
> see we're closer than you think.

	I actually think you're pretty close. :-)

> If you consider that the browser 
> gives you most of the things you think are missing from NW already, 
> and that with sigslot you can "connect" up these things to NW 
> primitives, you start to get the general idea of how you can use NW 
> to get where you're going (in large part) already.

	That's great, really!

> Try thinking of NW 
> as a plugin for the DOM and I think you'll get a better feel for how 
> you can use our stuff to make your app happen.
> 

	Ok, but unless I'm not understanding, there really isn't a "the DOM",
per se. There's the w3c dom, plus various implementations which differ in
minor but crucial ways - much like C varies on different compilers. Writing
portable 'C' code is a total nightmare, despite the fact the compilers are all
theoretically based on the same specs.

> Now, one of the reasons we haven't done the obvious thing that you 
> suggest here (which is to implement wrappers around what the browser 
> can already do) is becaues of the caveat that you outline. 
> Performance for the user in the browser is related not only to 
> runtime speed but also to initialization time.

	Yeah, I definitely get this. Has anyone figured out how much overhead
this would take?
	Also, if the "wrapping" isn't worth the overhead where the browsers
are actually consistent of implementation, it would still be worth wrapping
the places they differ, but - and here's the key part - it could be documented
together. Moreover, you never need the horrible

isCSS = (document.body && document.body.style) ? true : false;
isW3C = (isCSS && document.getElementById) ? true : false;

if( isCSS ) { ... }
else { ... }

style syntax. The toolkit takes care of it for you.

> Toolkits that have 
> taken a more heavyweight approach (like Isomorphic) have seen their 
> toolkit size after crunching move upwards of half a meg.

	Yeah, that seems pretty brutal. It looks like they are trying to
replicate the look, feel, and speed (argh) of Windows. This is definitely
not what I'm proposing.

> NW tries to have 
> it's cake and eat it too by providing a more friendly integration 
> path for apps that aren't going to be moving to an "everything in one 
> page" model any time soon, but also giving people who whant to do 
> that the tools they need. So, now it's your turn to tell me: is that 
> nuts?
> 

	No, that's right on. I think maybe we only differ in what we
consider a "friendly integration path", maybe.

	Austin

_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org