How do you intend to implement these features in the future. Are all non-web-protocols crippled implementations like in Opera? What happens, when a user wants feature X in IRC? Sure Opera is a powerful browser, but most features are not for casual users and not for power users, either. (IRC unusable due to incompatibility with bouncers, Mail without PGP, etc.)
If feature X is implemented in most cases, then we are talking about full-fledged FTP, IRC, XMPP, Mail, SSH, SMB, whatever clients. How does Otter treat this protocol implementations? Should Otter treat these implementations any different than the HTTP(S)/SPDY implementation? What about bugs/crashes? Is it possible that a Bug in the Mail-Client crashes Otter?What about plugins? What about extensions? Is it possible to modify the behaviour of the IRC-Client?
In my opinion Otter should be a browser in general. Not a "web browser" or a "smb browser" or a "file browser". Just a browser which supports many different protocols. Yes, the focus is HTTP and yes most protocols may be "read only" (like FTP or file://), but the software architecture should support any protocols. Features like bookmarks, history, etc. can be used by any protocol.
If I want to add libpurple/IM, how will I do that? Currently everything is pretty much hardcoded, yes? Maybe all of these "modules" should be treated like a dll/so whatever and loaded at run-time? Maybe they should be executed as processes and not as threads to prevent crashes? How are they going to communicate with "Otter"?
I think these are important questions which should be carefully answered, documented (wiki) and implemented (API), before tickets like #24 can be started. Currently the project is young and many features can be implemented on-the-fly, but in a few years a bad architecture is going to kill any new feature requests.
@Tante, sure, documentation would be useful, as when there i lots of code one shouldn't say that code itself is best documentation. ;-)
It' up to be decided, if it makes sense to go the same way as Konqueror did (and ended up being replaced by Dolphin and rekonq...).
We don't want let users think that Otter is bloated or something like that, it's hard to get it right. ;-)
And does anyone use rekonq seriously?
Quote from: Emdek on 2014-06-07, 09:10:13We don't want let users think that Otter is bloated or something like that, it's hard to get it right. ;-)What does "bloated" mean?
Careless coding (multi-process architecture promotes disregard for system resources!)
Konqueror was always too much integrated in KDE and focused more on the backend, than on the user interface (KIO, KHTML, ...). AFAIK dolphin still uses many parts of Konqueror (KIO) and attacked the faulty UI of Konqueror. I think Otter is more like Dolphin, which uses existing software to create a good user experience. (instead of developing highly developed backends like Konqueror did. Also I have to admit I don't know how much time has been used to develop the UI and how much time the backends)
What does "bloated" mean?
Just don't wait too long, until you develop a proper "Otter Module System", especially if you want a RSS reader in beta 3
Which provokes a question: once Otter adopts QtWebEngine (i.e. Chromium) instead of QtWebkit, it will necessarily become multi-process? Or not?
For some people feature-richness is bloat, while for others sluggish behaviour on limited resources is bloat, regardless of the feature set. I lean towards the latter definition.
Page created in 0.054 seconds with 39 queries.