Earlier I got links that request a new tab to work, I still got one minor (possibly unrelated) problem to work out and I think I'll have most of the features I want for 0.0.6, though since I just made a release I'm gonna wait a while for the next one and try to finish the cmake stuff and maybe have a tiny config dialog.
The last couple of days I've been reading various Qt Quaterly articles and have found them extremely informative (especially the one about designing APIs), several of them will definitely help in the future.
The more I work on Foxkit the more problems I'm encountering and the more I have to twist the API and internals, often undoing various things I'd previously done in the process. That may seem like a bad thing, but it's actually a good thing, as I've actually be solving the problems (and learning from my mistakes) and the API has been improving (some) from my changes.
The original way I had it setup couldn't handle the needs of a real browser, but it's slowly getting to the point where it actually takes only small modifications to get things working. I tried a few ways to solve the problem with links that wanted to open in new tabs, the first was an attempt to use signals with a non-void return type (can't do that), then I tried to give it a single argument, a pointer that the slot would set to the page it'd create which would result in a blank tab, lastly I slightly modified how tabs were created, I moved most of the code into a function that took a pointer to a webView and did all the connecting/inserting into the tab bar which made it easy to solve my problem.
The webView::createWindow() function would create a pointer to a new instance of a webView object then emit a signal with the pointer as one of the arguments, the slot in the foxkit object would take that pointer and do exactly the same as if it'd gone through newView (as newView does the same thing as the createWindow() function.
This prevents code duplication, and code duplication is Very Bad. Not just because it has a (generally trivial) impact on performance, but because I'll update one version of the code but forget to update the other and then have no clue why things are breaking :P
All-in-all I'm extremely happy with Foxkit, I'm not to the point where I'm gonna ditch Konqueror/Opera, but I'm actually getting to the point where that seems reasonable.
4 comments:
Hi,
I wonder how far you are still working together with the Arora people - I thought they solved the Tab problem and you would just take over their solution?!
Or would that cost even more work?
I wonder how far you are still working together with the Arora people
Unfortunately there's pretty much no communication. A while back I was trying to contact both the Arora people and the person working on the WebKit KPart though life got in the way before I was actually able to contact anyone directly. Since then I've barely been on IRC and I had pretty much forgotten about trying to contact any of them, and now that you've remdined me I'm gonna barely be able to get online so I'll probably forget again before I get a chance :P
I thought they solved the Tab problem and you would just take over their solution?!
Generally they've solved the various problems before me :P I do frequently look at Arora's code to see how they solved a problem I'm having but generally I won't like their implementation for some reason (it creates a direct dependency on the parent, it would require too many changes to my code, or I simply have no clue what they're doing are common reasons :P). The createWindow() function is an example of creating a direct dependency on the parent which I'm trying to avoid because it makes it harder to change the design later and unlike Arora's developers I have pretty much no experience designing interfaces :P
Or would that cost even more work?
Using just the concepts works okay, but using actual code generally would require too many changes. Plus, how would I learn if I don't frequently burn myself by always making mistakes? :P
I really need to work on keeping my posts short :P
Thanks for the detailed answer - I'm looking forward to have a look at Foxkit to see how it works for me :)
The most important parts are indeed favorites (implemented afaik), tabs (also implemented) and kwallet integration. What's the state of the last part?
Actually favorites/bookmarks aren't implemented yet, though they're one of the things I'm wanting to get to soon. Short term I'll probably go with something traditional and hard-coded into Foxkit, but I'm really wanting to use plugins/kross for long-term instead so it'll be possible to experiment with using Nepomuk and tags and maybe come up with something quite different than normal systems.
Tabs should be working pretty well, though theres a few more smaller features I have planned for later (mainly tabbar context menu, tab reordering, and some tweaks to windows opened by javascript). If you find any sites that act funky with tabs I'd definitely like to know so I can make sure they all work.
Currently there's no sort of wallet integration, and AFAIK theres none possible with the version of QtWebKit in Qt 4.4 (planned for 4.5 I think?). If Arora or the KPart figure out a work around I'll definitely try to implement it (wallet is one of the features I use a lot in other browsers).
It's still not really ready for prime time, though the list of features blocking it for me is shrinking quite quickly. This summer I actually accomplished most of the things I was hoping to be able to do (as well as several other things I hadn't thought about) so I feel pretty confident that I'll be able to have at least basic versions of everything before too long.
Post a Comment