Remember KDE Fiber? It was some of the best vaporware ever. Remember when whatshisface was thinking of making it use lots of plugins for customization?
Why not make that a reality? We make a web browser that isn't actually a browser at all, just a plugin framework? It's just a bare window to hang things on and the rest is plugins. This will include not just plugins similar to firefox addons, but EVERYTHING. The layout engine? Plugin. Javascript engine? Plugin. Want a fancy address bar that let's you do X? Plugin. Want vertical treed tabs that are color coded? Plugin. Want to change layout engine on a per site basis? Plugin. Want to use web extension plugins? Get the web extension plugin plugin. Like a nanokernel, the "browser" is just a skeleton to make sure the plugins can all talk to each other and work together. It's the fleshy plugins that do the actual work.
Browser threads are a Holla Forums tradition at this point,
Wyatt Gray
I see. You're one of (((those))).
That does sound pretty good, but it would be pretty hard to make it work. How would you prevent conflicts, and plugins that affect the behavior of other plugins would probably have to be dependent on the plugin that it's compatible with unless there was a clear and enforced standard to ensure modularity. Also, you know that if it caught on the kikes would try to test what plugins you have installed, and they would make proprietary plugins required to use their sites and it would be shit all over again. At least it would solve the problem of different browsers having cool shit but also having cancer, and being unable to just have one godly browser just for you.
Benjamin Edwards
Look at the shills go on this thread.
Yes, absolutely, we need a browser where you can choose what parts actually run, more granular than being able to just toggle JS on and off. Something which could be used to prevent (((tricks))) but still provide a usable experience even on pages like Youtube.
In my mind it could use youtube-dl and other such tools to get at media normally hidden under megabytes of coin-mining JS, and possibly present itself (to the server) as some normalfag browser but only running / displaying the text, images, and videos directly.
Let's break web 2.0.
Owen Richardson
Is this a good imagining of how a basic browser built in such a way would work?
Obviously its just a simplification, but it has the general idea. You could take an example from how windows and X11 work, in that they have either "events" or "messages", and then a program will have a blocking function like this: while(get_message(&msg)){ switch(msg.msg){ case HTMLR_NEW_HTML: render_html(); break; default: break; }} Basically, the whole idea is that everything you do is in response to some kind of message passed to you by another component.
Brandon Mitchell
The trick is to use the components, libraries, etc. which are already available and just glue 'em together. I don't even know if we want an HTML renderer, we could do the whole thing in Emacs (for example only), stripping out the useful text and images from the HTML and rendering them in some sandbox where no actual downloaded code is running would be ideal.
I don't want to be overly critical, there's no reason why this thing can't be modular as heck and have different 'front ends' from a full blown CIA nigger Firefox Quantum front end to just a plain ass text window.
Jaxson Reed
Well the idea is that this is just an example model, and anything could look much different. But I get you about how this is a pretty "graphics oriented" example, and doesn't even consider text mode.
I think that the only constant that we have right now is that there has to be a module that "renders" the final result, be that putting text on a console or bitmaps on a window... and a module that obtains the HTML from the internet. I wasn't putting those components there to say that they would be required, just an example of how someone could set theirs up. Pic related is probably the simplest version of this model I can think of, where you can still call it a web browser.
Luis Howard
OP here. My idea was that the browser would basically open a gtk window, and the rest of the program would be a framework for various types of plugins to communicate with each other. Things like layout engines would be wrapped in a translation layer and plugged in. You could webcore as as your HTML engine, and V8 for JavaScript... If you wanted to. A management plugin could even allow you to use a specific engine for a specific website, assuming you have the necessary engine plugins.
The same would be done for all the graphical components, as well as the more internal workings of the browser. The idea being that it's relatively easily customizable but to an autistic degree. I'm phoneposting at work so I'm not being very eloquent. When I get home I'll try to explain myself better in more practical terms.
Bentley Phillips
OK, OP here again.
I've decided to to call the framework "Scaffold" for hopefully obvious reasons. I went ahead and created a shithub for it at github.com/SpaceBudokan/Scaffold so we can at least pretend to make this a reality one day.
The basic premise is that Scaffold is a collection of API's to assemble a browser from various parts. has a very good idea of what I'm talking about. Scaffold is the arrows in his pic. We create APIs so that we can modularly swap out any basic part of the browser. One of my main questions is how far to take it. I was orginally thinking of doing all the interface work in GTK+, but even the interface could be put behind an API, so that one could define general widgets, and they can be used with GTK+, Qt, fltk, translated to text for use in the terminal, whatever.
Also an API for talking with and between the layout and javascript engines. I feel like I've already said enough about this part, but it's what I think makes it truly unique.
Lastly would be an API to make more conventional plugins. Still, it would allow one to make extremely customizable things like some kind of exotic address bar like Vermette talked bout, weird tab systems, or even some other weird way or organizing your pages. Maybe for whatever random reason you want you tabs, address bar, and and each in a separate window from where your webpage is displayed. You could do that.
Ryan Rodriguez
LOL. Holla Forums is full of LARPers sad
Benjamin Diaz
Yes. no code for an idea I had while I was taking a dump at work earlier today. Now I'm going to bed.
Dylan Harris
babbys first maymay idea I hope you like preview-less file pickers :^^))^)
Aiden Cook
It's thumbnailless file pickers. Meme it right.
Nicholas Torres
autism
James Brown
But GTK does have previews. It does,'t have the specific subset of previews "thumbnails", but it lets you view the image when clicking over it.
Hunter Lewis
I agree that making the base system in GTK is a mistake. Instead, scaffold should be more like a protocol with a required plugin providing a way of drawing graphics to the screen.
The only thing the framework should be concerned with is spinning up the plugins and helping pass messages IMO. The only concern that I have with the diagram that I made is that it implies that each component is managing a seperate bitmap, which is a wasteful use of memory, but maybe that's a good idea. You could also pass pointers to one big bitmap, and then tell it to draw into a sub-bitmap...
It sounds like each component would either only be written against a few other components, or they would have to have a lot of compatibility code from handling unique messages. Maybe the API should strictly enforce certain core components to behave in a certain way, for example you could require that an HTML renderer must be able to implement something such as: "M_REQUEST_BITMAP" and "M_REQUEST_SUB_BITMAP". Then you would ensure that each component is written against each other, and it solves the problems of components not being compatible with each other, since they have to be compliant and implement a common set of functions. This would prevent people from just writing modules against one other module and having a dependency hell of modules. OpenGL has done this kind of thing - to be compliant with a specific OpenGL standard, you have to implement a series of features, and then you can also optionally implement extensions that are standardized, but not required. But, only certain components would need certain levels of standardization. A display manager has to be able to make a request and get something back, or else it just doesn't work...
Josiah Bennett
your best bet is to construct a site like hooktube using ytdl then, i'm sure others would help with development and financing as well, once it gets going which is usually the problem with these ideas however, defeatism helps no one
Lincoln Green
Will it be written in Rust?
Jaxson Lopez
No. It will be in c, but you can write your own plugins in rust if you can keep the cocks out of your ass long enough to get anything done.
