[ / / / / / / / / / / / / / ] [ dir / choroy / fp / htg / leftpol / lewd / shame / tijuana / v9k ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): 21deaae19e034b0⋯.png (434.91 KB, 807x700, 807:700, daa67050aab9e3c31ddb60f9a3….png) (h) (u)

[–]

 No.830133>>830158 >>830294 >>830404 >>830617 [Watch Thread][Show All Posts]

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.

 No.830135>>830136

>what is browser.html

https://github.com/browserhtml/browserhtml

retarded nigger. just install firefox quantum

saged and reported for another fucking browser thread


 No.830136>>830138

>>830135

>just install firefox quantum

but I don't like the taste of cock


 No.830138>>830139 >>830158 >>830285

>>830136

why did you post a tranny then?

saged and reported


 No.830139

>>830138

>why did you post a tranny then?

aw lame. guess I'll have to delete it.


 No.830151>>830153

It has hips and tits. Looks like a girl to me.


 No.830153>>830156

>>830151

>tits

where?

saged and reported btw


 No.830156>>830176

>>830153

The round things on the chest.


 No.830158>>830177

>>830133 (OP)

Hell yes I remember fiber! I really had my hopes up. I'm loving this idea. We should get started on a logo.

>>830138

Pretty sure that's a loli, fag.


 No.830176

>>830156

>round things

you mean "O-U"? no tits sorry.

saged and reported


 No.830177

>>830158

>Pretty sure that's a loli, fag.

yeah. a male loli.

saged and reported


 No.830285>>830404

>>830138

>the milquetoast (((/pol/)))tard fears the anime


 No.830289>>830329 >>830397

It's called uzbl

sage for browser thread, stop bumping these


 No.830294

>>830133 (OP)

Hi, Idea Guy™, I'm Logo Guy™.

I'll get started on the logo ;^)


 No.830329

>>830289

> https://en.wikipedia.org/wiki/Uzbl

> Engine: WebKit

Well so much for that one. Next!


 No.830397

>>830289

Browser threads are a /tech/ tradition at this point,


 No.830404

>>830285

>implying he's not a goon or normalfag

>milquetoast

I see. You're one of (((those))).

>>830133 (OP)

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.


 No.830617>>830828

>>830133 (OP)

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.


 No.830622>>830624 >>830722

File (hide): b19b22674ee8464⋯.png (57.21 KB, 800x600, 4:3, mockup.png) (h) (u)

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.


 No.830624>>830644 >>830664

>>830622

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.


 No.830644

File (hide): 6bd644ccda15984⋯.png (12.71 KB, 325x481, 25:37, mockup_simple.png) (h) (u)

>>830624

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.


 No.830664

>>830624

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.


 No.830722>>830734 >>830814

File (hide): f688f0da12019d1⋯.jpg (30.61 KB, 600x750, 4:5, I_Want_To_Believe.jpg) (h) (u)

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 https://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. >>830622 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.


 No.830734>>830750

>>830722

>no code

LOL. /tech/ is full of LARPers

sad


 No.830750

>>830734

Yes. no code for an idea I had while I was taking a dump at work earlier today.

Now I'm going to bed.


 No.830757>>830770

babbys first maymay idea

>gtk

I hope you like preview-less file pickers :^^))^)


 No.830770>>830805

>>830757

>I hope you like preview-less file pickers :^^))^)

It's thumbnailless file pickers. Meme it right.


 No.830805>>830811

>>830770

>thumbnails aren't previews

autism


 No.830811

>>830805

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.


 No.830814

File (hide): 44a3aa05426fa68⋯.png (38.55 KB, 800x389, 800:389, standards.png) (h) (u)

>>830722

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


 No.830828

>>830617

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


 No.830831>>831062

Will it be written in Rust?


 No.831062

>>830831

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.




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
32 replies | 4 images | Page ???
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / choroy / fp / htg / leftpol / lewd / shame / tijuana / v9k ][ watchlist ]