[The Q.BATi Team]

The Q.BATi Project wants developers to help make the best web browser ever. Q.BATi will use the Gecko rendering engine in conjunction with an OSX native interface: The best of both worlds. The Q.BATi project has been in progress since the end of last year, but we're always looking for more help. More information is available at the above link. If you're interested in participating, please let us know, either through responding to this thread, through our SourceForge Forums, or through email, at revitup@users.sourceforge.net.



------------------

<A HREF="http://qbati2.source
forge.net/" TARGET=_blank>The Q.BATi
Project</A>

[Angus_D]

Perhaps you'd like to actually stop talking and work on getting the base work started (and no I'm not talking about a partial build of Mozilla and interface ideas, these are not the first priority - getting a full idea of how the hell the app is going to work is the first priority, followed by implementing some of it, followed by tweaking the GUI) before you start posting everywhere asking for help.

Sorry, but this isn't the first time you've asked for help.

[The Q.BATi Team]

&lt;Sorry. Double Post.&gt;

[This message has been edited by The Q.BATi Team (edited 05-08-2001).]

[The Q.BATi Team]

Angus_D:

Our apologies for obviously upsetting you with our cries for help. We are only a beginning open source project, just feeling our way around in the new and strange world of OS X. As such, we need all the help we can get doing exactly what you have said: solidifying an idea and implementing it.

At the moment Mozilla itself is mostly ported, but we now need to focus on "wrapping" it (well, the needed portions) for use via Cocoa. With this effort we need all the help we can get. We are only a few strong. More eyes means better code.

As for "getting a full idea of how the hell the app is going to work," we feel the most important first step is to get the building blocks ready. A solid foundation is most important. Mozilla.org has worked for two years to develop a flexible internet enabled engine. This is the terrible misconception about Mozilla. Everyone is waiting for a browser (which would be rather nice. I know I'm waiting), however it is more than that (which is, unfortunately, why there is no new Netscape in 2+ years). Mozilla has become the framework for cross platform, internet enabled applications. XPCOM, XUL, Gecko, these are the true jewels of the Mozilla project. What we of Q.BATi are looking to do is port these in the best possible manner for OS X (as a set of Cocoa frameworks), and then build a great browser from this start.

Point of this long rant: there are multiple tracts of this project running simultaneously. One group is working on "wrapping" Gecko, XPCOM etc. They can use all the help they can get to get this done as soon as possible. Most everyone else is working to create the interface. For this we could use people more experienced with interface design (most importantly Interface Builder) to help out, and anyone/everyone who wishes to add ideas as to what they would like in a browser. It would be nice to have increasing amounts of help. As they say, many hands make light work...

------------------

&lt;a href="http://qbati2.source
forge.net/" target="_blank"&gt;The Q.BATi
Project&lt;/a&gt;

[This message has been edited by The Q.BATi Team (edited 05-08-2001).]

[PerfectlyNormalBeast]

When the many hands are spread over the internet working on some non-paying gig... too many chefs spoil the software... or something like that.

-my 2 cents

[parallax]

Even still, before you appeal to a forum like this one for open-source help, it would be beneficial to have a solid start.

Beast is right -- if you want the browser to take on its own shape (and not get out-of-control), you should have some clear, specific goals set, and clear, specific work done. Just saying "Let's make the best browser in the universe and all it's parallels!" will -not- appeal to unpaid workers.

[The Q.BATi Team]

Hello, once again.

I'm sorry we were so vague before. To us it is perfectly clear what the goals we have set out are, so others not understanding seemed nonsensical.

We shall now try to clarify our project goals and direction as, well, clearly as possible:

1. We are looking to utilize Mozilla's Gecko as the HTML rendering engine for Q.BATi. As such, we are working towards the FizzillaMach port, while simultaneously working on creating the hooks necessary to make XPCOM and Cocoa work well together.

2. We are creating an interface which will use a dockable pallet for navigation (as forward/backward/stop/reload are global functions, an infinitely deep side pallet has been deemed the most efficient solution), thus leaving the most possible room in each window for browsing (putting only the URL bar at the top of each window, with a small throbber type animation, and buttons to allow for the next feature).

3. A "drawer" of sorts to pop down from the top of the window for certain functions. This is somewhere between a sheet and a drawer, more like the tabbed windows at the top of Project Builder than anything else we've see. The buttons next to the URL bar would pop this drawer down. Contained within (depending on which button has been pressed) would be a visual history of the window, a site browsing feature.

4. This site browsing feature consists of an alternate way to navigate a site. Q.BATi will pull the links from a page, and display them as folders in a three pane browser view. Thus the links from a site can be drilled down as if they were a file system. An example of this would be visiting Apple's page, and from the site browser being able to quickly drill down to the Apple Store, the iBook page, and then one of the configurations.

5. The only other feature to mention is a pad (along the lines of Cyber Dog's note pad) for holding Bookmarks/Favourites. This is the only fluctuating feature at the moment, as there is still some debate as to how this could be best implemented.

I hope this gives a better view of where we are and where we are going. Admittedly, we are still looking into other ideas, however these are the core items on which work has begun. We are a small group of individuals, and are looking for all the help we can get, to enable this project to progress as quickly as possible.

The focus has thus far been defining where we are going. Now the focus is working to actually get there. For that, we could always use more help.

[sadie]

The reason we keep asking for help is that you people haven't come up with any useful ideas yet! OS X is in desperate need of a better browser, and when we try to write one all you can say is "what's it got to do with us?"

Technically, we have a good idea what we're doing: wrapping Gecko, then making a Cocoa interface. We just need good ideas as to what to do with the interface.

If you have a real idea, or think you may really be able to achieve something, go ahead. Otherwise, stop moaning.



Be nice to people. The outnumber you six billion to one.

[Gavin]

If you want to make a great browser start with OmniWeb's interface then plop in Gecko as the rendering engine.

That's it.

Keep it simple and 'Mac like' (netscape never was)
Don't get bogged down by adding 'cool' stuff.
Don't waste your time with skins and throbbers.

Focus on a stable, tight, fast, standards based browser for version one and you'll have all the help you need for the goodies in version 2.

The only things I miss now are speed and a better way to deal with my 15 bazillion bookmarks; I want to group, sort, search, label, etc.

[Angus_D]

You didn't upset me, I was just pointing out that this isn't the first time you've asked for help, and there are probably reasons why you're not getting much.

Originally posted by The Q.BATi Team:
1. We are looking to utilize Mozilla's Gecko as the HTML rendering engine for Q.BATi. As such, we are working towards the FizzillaMach port, while simultaneously working on creating the hooks necessary to make XPCOM and Cocoa work well together.

FizillaMach is currently not building properly. I know for a fact someone is working on it, and I am not under the impression they have anything to do with Q.BATi (which is a really odd name, by the way, and can be interpreted differently in the UK :/)

2. We are creating an interface which will use a dockable pallet for navigation (as forward/backward/stop/reload are global functions, an infinitely deep side pallet has been deemed the most efficient solution), thus leaving the most possible room in each window for browsing (putting only the URL bar at the top of each window, with a small throbber type animation, and buttons to allow for the next feature).

Ahh, you wish to integrate well with OS X but yet decide to go ahead and waste time redesigning the interface already! First of all, get Gecko working. Then embed it in a small Cocoa browser with no functionality other than basic support. Then you can start working on all your wonderful new interface ideas. I personally don't see what's wrong with the toolbar, it can be set to display text or icon or both, is at a standard location, and if you put it at the side then it's not taking up any less space, just taking it up in a different format.

3. A "drawer" of sorts to pop down from the top of the window for certain functions. This is somewhere between a sheet and a drawer, more like the tabbed windows at the top of Project Builder than anything else we've see. The buttons next to the URL bar would pop this drawer down. Contained within (depending on which button has been pressed) would be a visual history of the window, a site browsing feature.

Sounds interesting, but I'm not sure how useful all these things would be in everyday browsing.

4. This site browsing feature consists of an alternate way to navigate a site. Q.BATi will pull the links from a page, and display them as folders in a three pane browser view. Thus the links from a site can be drilled down as if they were a file system. An example of this would be visiting Apple's page, and from the site browser being able to quickly drill down to the Apple Store, the iBook page, and then one of the configurations.

Shouldn't it be up to the site's designers to define how the site should be navigated?

5. The only other feature to mention is a pad (along the lines of Cyber Dog's note pad) for holding Bookmarks/Favourites. This is the only fluctuating feature at the moment, as there is still some debate as to how this could be best implemented.

I hope this gives a better view of where we are and where we are going. Admittedly, we are still looking into other ideas, however these are the core items on which work has begun. We are a small group of individuals, and are looking for all the help we can get, to enable this project to progress as quickly as possible.

The focus has thus far been defining where we are going. Now the focus is working to actually get there. For that, we could always use more help.

Yes, I was aware of all of this already. I had a quick poke through your forums, which have basically all been a load of nattering over UI issues. Perhaps you should get some code working first, non-programmers trying to interest coders in working on projects often fail because all they have to show for their work is a load of talk and some mock-up UI. If you got a small Cocoa shell for Gecko up and running, that could help drum up some interest.

[rwc9785]

I agree with Angus. All you really have is an idea, not too much more. I don't have time to make your idea a reality. There is still lots of research to be done to even begin to make a foundation to this web browser. Show us what you have don't tell us your dreams.

Sorry man, all you have is an idea. I haven't seen anything else.

Ryan C

[PerfectlyNormalBeast]

I didn't mean to be harsh. I'm not against open source projects with developers distributed over the internet. I just speak from lots of personal experience when i say that it's extremely difficult to begin coding a project with many distributed developers.

Have one or two people get a frameworks for your application set up in code. Decide how the source tree is to be strucutred. Write some of the basic code. Angus_D had a very good idea when he suggested you simply get gecko to display a page in a window without much interface. Set up a CVS system. Then when you've got a solid start, you'll get much more of a response from developers, and you'll have much more for them to do.

[The Q.BATi Team]

Howdy.

No, no one's been too harsh. A dose of reality is generally a good thing. :-)

At any rate, it is one of the wonderful chicken-and-egg scenarios. How does a group with minimal coding ability but a good idea attract help, if people won't help unless they have more than just an idea? Fortunately, we have attracted some great help over our last five months. There is just always room for more. Besides, we'd like to keep our name out there. (of course, coming off as a whinny bunch of incompetents, probably wasn't the best way to start :-) . . . )

I think our goal at present is to focus all the programmers on the Gecko/XPCOM framework porting, and all else on interface design watch. Setting up a simple working browser first sounds like a great idea. That should be our first step when the XPCOM framework is all set to go. After that, we will work on hooking it into whatever interface we have created.

Always good to get an outside perspective.

[graffix]

Always good to get an outside perspective.

Well, you actually got an 'engineers' perspective...
You can see now why there are many levels of hierarchy in any company, and the 'creative types' are well-insulated from the program engineers (so the engineers don't destroy their egos)...
Engineers really don't want to conceptualize... they just want to have focus and get down to work... which is the perspective you have gotten.
Instead of asking for programming help, you should have some sort of forum on what features, etc. you'd like implemented, and then draw up at least a 'plan' on what the browser will entail. This will at least be a blueprint that you can have 1 or 2 software engineers take a look at and fine-tune (and tell you what will work and what won't). Then take that plan back to the forum and discuss the changes that need to be made, and then begin asking for programming help...
It also makes it much easier to split up the coding work when each bit is already planned and you'll know how it'll interface with the rest of the code... it's no fun to go back and re-write code to implement methods that you didn't figure you'd need in the beginning, but discover that the program won't function without them...
Just my .02¢
g.

------------------
First there was man,
then there was
Macintosh