Re: Questions about netwindows, probably a faq

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey,

On Wednesday 07 April 2004 1:05 am, Austin Schutz wrote:
> On Sun, Apr 04, 2004 at 01:06:47PM -0800, Alex Russell wrote:

[ snip ]

> > As for raw number of widgets, I don't think we're the most
> > capable in that regard, but we're getting there.
>
> 	My own "pie in the sky" wish is to be able to have a toolkit to
> write web applications with. This, in my mind, means replicating
> (where necessary) all the lowest level objects available in
> windowing toolkits and aggregating them into widget classes where
> possible. Certainly you can't do everything in javascript (such as
> canvas widgets), but you can get most of the way there as
> netwindows demonstrates.

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.

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. 
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.

> 	With a full suite of basic widget classes and a message passing
> mechanism (both of which netwindows has to a great degree) it will
> be possible to replicate many complex applications directly on the
> web, where all the UI stuff is directly handled by the client but
> application logic is done by the server, maybe in an explicit
> fashion using SOAP (web services in ms parlance) as a language
> independent API.

You "get it". Nice to see = )

> 	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.

> 	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.

> I noticed the signal/slot mechanism
> which is similar to that used by qt, but there's no mention that
> supporting qt base widgets is a goal. 

It's not. I work on widgets that people express a need for.

> Also, unless I missed it,
> there doesn't seem to be a set of geometry management tools - I
> think that's what they're called - methods such as 'place' and
> 'pack' as there are in other toolkits. 

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. 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.

> 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.

> 	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. 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. 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.

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. Toolkits that have 
taken a more heavyweight approach (like Isomorphic) have seen their 
toolkit size after crunching move upwards of half a meg. At that 
point, I think your toolkit looses it's credability as a 
browser-friendly app platform, in part because it takes so damn long 
to just re-eval() your toolkit on multiple pages. 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?

Regards

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAdBBYoV0dQ6uSmkYRAh5kAJ99hG+esS+/3dvJj+zQmV30glGAkwCeLCRK
k15mWMkFLrobRtn1TED+Qec=
=e1YW
-----END PGP SIGNATURE-----


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