On Wed, Oct 23, 2019 at 8:34 AM Henri Sivonen wrote:
> I'm curious how developers of libstdc++ and libc++ view the notion of
> WebKitGTK+ as a platform capability. The C++ standard libraries are
> arguably for Linux while the "platform capability" named (WebKitGTK+)
> is arguably a Gnome thing
On 25/10/2019 21:52, Eric Rescorla wrote:
On Fri, Oct 25, 2019 at 12:21 PM Botond Ballo wrote:
My understanding (which may be wrong!)
is that the purpose of the C++ proposal isn't to enable creating Web
browsers around the API but to use the API to render the GUI for a
local C++ app whose
> My understanding (which may be wrong!)
> is that the purpose of the C++ proposal isn't to enable creating Web
> browsers around the API but to use the API to render the GUI for a
> local C++ app whose primary purpose isn't to browse the Web, so I
> assume "I want a URL bar" is the opposite of
On Thu, Oct 24, 2019 at 12:30 PM Gijs Kruitbosch
wrote:
> From experience, people seriously underestimate how hard this is -
> things like "I want a URL bar" or "I want tabs / multiple navigation
> contexts and want them to interact correctly" or "users should be able
> to download files and/or
Is there some visibility into the feedback by other participants (esp.
other browser vendors) and why they think this is a good idea? What are
the arguments *for* this thing, and have they engaged with our arguments
against at all?
As a desktop Firefox person, "embedding" Gecko and providing
-- Original Message --
From: "Henri Sivonen"
Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a
On Tue, Oct 22, 2019 at 11:55 PM Botond Ballo wrote:
> Given that, would anyone be interested in reviewing the proposed API
> and providing feedback on its design? I feel like the committee would
> be receptive to constructive technical feedback, and as a group with
> experience in developing
We that's bleak. Get pumped for a surge in "Download our desktop app for
the full experience"!
Rather than spending our limited resources giving guiding technical
feedback to proposals we fundamentally oppose, I would rather see us
putting effort into satisfying the target user stories with a
Hi folks,
I wanted to give an update on the "web_view" C++ standard library proposal.
I have relayed the feedback received on this thread on multiple
occasions, and our concerns about this proposal as a browser
implementer have been noted by the committee. However, the proposal
has been received
Yeah, a standard web_vew library being part of the C++ standard is not a
good idea. It's far too huge a thing with far too many potential pitfalls
and dangerous consequences, and is an overweight solution to what should be
a comparatively lightweight problem.
If the goal is just to have a
Botond Ballo wrote on 2018-07-18 09:45:
As we have some experience in the embedding space here at Mozilla, I
was wondering if anyone had feedback on this embedding library
proposal. This is an early-stage proposal, so high-level feedback on
the design and overall approach is likely to be
Ted wrote:
>Honestly I think at this point growth of the C++ standard library is an
>anti-feature. The committee should figure out how to get modules specified
>(which I understand is a difficult thing, I'm not trying to minimize the
>work there) so that tooling can be built to provide a
Reading between the lines, it seems like the committee's aim is to take
something that is widely understood and used, broadly capable, and in the
big picture relatively well-defined (i.e. the Web), and incorporate it into
the C++ standard by reference.
The problem is that the *relationship of web
On Thu, Jul 19, 2018 at 5:35 PM, Mike Hommey wrote:
> Other than everything that has already been said in this thread,
> something bugs me with this proposal: a web view is a very UI thing.
> And I don't think there's any proposal to add more basic UI elements
> to the standard library.
Not that
On Wed, Jul 18, 2018 at 12:45:30PM -0400, Botond Ballo wrote:
> Hi everyone,
>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical
Hear, hear and well said!
On 7/19/18 11:53 AM, Ted Mielczarek wrote:
> On Wed, Jul 18, 2018, at 12:45 PM, Botond Ballo wrote:
>> Hi everyone,
>>
>> With the proposal for a standard 2D graphics library now on ice [1],
>> members of the C++ standards committee have been investigating
>> alternative
On Wed, Jul 18, 2018, at 12:45 PM, Botond Ballo wrote:
> Hi everyone,
>
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and
On Wed, Jul 18, 2018 at 9:21 PM, Bobby Holley wrote:
> In practice, I kind of doubt that standard libraries would actually include
> multiple implementations of the web platform.
>
It also seems like the implementation(s) that get included will essentially
be those those authors devote the
On Wed, Jul 18, 2018 at 8:04 PM, L. David Baron wrote:
> It feels like this bakes into the C++ language the idea that a
> machine only ever needs a single implementation of the web platform.
>
> I (and I think many others at Mozilla) think that users are better
> served by competition among
On Wednesday 2018-07-18 12:45 -0400, Botond Ballo wrote:
> With the proposal for a standard 2D graphics library now on ice [1],
> members of the C++ standards committee have been investigating
> alternative ways of giving C++ programmers a standard way to write
> graphical and interactive
On Wed, Jul 18, 2018 at 5:31 PM, Boris Zbarsky wrote:
> If the intent is that the default behavior is to speak http, what are the
> committee's thoughts on things like sandboxing, spectre mitigations,
> process-per-origin, etc?
>
> This last is particularly concerning in terms of API surface,
On 7/18/18 5:18 PM, Botond Ballo wrote:
My reading of the proposal is that that's an extension mechanism for
the program to be able to override handling of standard URI schemes,
or invent new ones (such as for serving a page from a string in the
C++ program's memory), but if e.g. the program
On Wed, Jul 18, 2018 at 5:01 PM, Boris Zbarsky wrote:
> On 7/18/18 4:54 PM, Botond Ballo wrote:
>>
>> Either to include one, or to be able to find and use one provided by
>> the OS/platform.
>
>
> Ah, ok.
>
> And in the latter case, to disable whatever network stack the OS-provided
> thing has,
On 7/18/18 4:54 PM, Botond Ballo wrote:
Either to include one, or to be able to find and use one provided by
the OS/platform.
Ah, ok.
And in the latter case, to disable whatever network stack the
OS-provided thing has, if any, and substitute its own, right?
-Boris
On 7/18/18 4:59 PM, Nathan Froyd wrote:
I can imagine that embedded implementations wouldn't include
, their documentation would be clear about this, and their
users would be OK with this situation.
Oh, sure. I was talking specifically about stdlib implementation that
are aiming to comply
On Wed, Jul 18, 2018 at 4:54 PM, Botond Ballo wrote:
> On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky wrote:
>> Am I correct in my reading that this would require the C++ standard library
>> to include an implementation of the web platform?
>
> Either to include one, or to be able to find and
On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky wrote:
> Am I correct in my reading that this would require the C++ standard library
> to include an implementation of the web platform?
Either to include one, or to be able to find and use one provided by
the OS/platform.
Cheers,
Botond
CCing snorp.
I guess it's interesting to see how the geckoview API differs from the
webview API, and which of those differences are related to goal of that
C++ API, and which are more browser-focused.
And if the C++ API should be also browser-focused, in the end.
Not making any statement on
On 7/18/18 12:45 PM, Botond Ballo wrote:
A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
Botond,
Thank you for
On Wed, Jul 18, 2018 at 3:32 PM, Jeff Gilbert wrote:
> It feels like the committee is burnt out on trying to solve the
> general library problem, but contemplating something massively complex
> like this instead doesn't follow, and is an answer to the wrong
> question.
>
> Make it easier to
It feels like the committee is burnt out on trying to solve the
general library problem, but contemplating something massively complex
like this instead doesn't follow, and is an answer to the wrong
question.
Make it easier to integrate libraries and we wouldn't see kludge
proposals like this.
Hi everyone,
With the proposal for a standard 2D graphics library now on ice [1],
members of the C++ standards committee have been investigating
alternative ways of giving C++ programmers a standard way to write
graphical and interactive applications, in a way that leverages
existing standards
32 matches
Mail list logo
