ially there are two tiers of app
trust. Anything not flatpak (and snappy, etc) is considered trusted on
the user bus, and can do "anything".
So, in the golden future where all normal apps are sandboxed this could
work, but for current distros there is no secure way to authenticate
apps.
--
=-
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
> On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
> > Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
> > the idea of limiting the surface area as much as possible, to not
> > only
> > make it explicit as to w
On Thu, 2015-07-09 at 13:38 +0300, Pekka Paalanen wrote:
> On Thu, 09 Jul 2015 11:37:06 +0200
> Alexander Larsson wrote:
>
> > On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> > > My issue with this is that you're tying two things together. You
&g
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
> My issue with this is that you're tying two things together. You want
> access to """a surface""", and you think you can do this by having
> global cross-client objects and handles and such. I don't see a need
> for this. We can just add
On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote:
> > However, the problem I have now is different, in that it involves
> > an
> > existing, less privileged client initiating a higher privileged
> > operation (in a controlled fashion) and the higher privileged
> > client
> > needing to refe
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> Hi,
> None of them will really work.
>
> This thread has sadly degenerated into: 'what if Wayland's object
> model was totally different? what if some of its explicit core design
> principles were thrown out the window?'. Realistically, tha
On Fri, 2015-07-03 at 18:10 +0800, Jonas Ådahl wrote:
>
> With "see" I suppose you mean "be aware and map", because it wouldn't
> see the content.
Sure, there is no need for the other client to ever see (or change) the
contents of the window (or get events or whatever). This is purely
about bein
ce it can't open two (consecutive) surfaces
both with the other surface as the parent.
I think the sandboxed app should create a xdg_foreign for *its*
toplevel, and then the "open file dialog" should be able to use this as
a parent for its xdg_surfaces.
--
=-=-=-=-=-=-=-=-=
ng contents or state.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's an oversexed skateboarding hairdresser with a winning smile and a
w
On tis, 2015-04-21 at 14:23 +0300, Pekka Paalanen wrote:
> On Tue, 21 Apr 2015 11:17:17 +0200
> Alexander Larsson wrote:
>
> > I just spent some time debugging the wrong thing due to a weird change
> > in wayland 1.5. A new queue was introduced for the display itself,
>
a bit less confusing?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a Nobel prize-winning neurotic dwarf with a win
On ons, 2013-11-13 at 11:54 +0200, Pekka Paalanen wrote:
> On Tue, 12 Nov 2013 16:14:36 -0800
> Bill Spitzak wrote:
>
> > Pekka Paalanen wrote:
> >
> > >> The source rectangle *must* be in buffer pixels. Putting it in
> > >> buffer_scale units makes absolutely no sense, as the buffer_scale is i
On ons, 2013-05-29 at 07:55 -0700, Bill Spitzak wrote:
> On 05/29/2013 12:31 AM, Alexander Larsson wrote:
>
> >> I don't think you can avoid non-integer scaling. What happens if a
> >> client says it's scale is 3 and the output has a scale of 2? This is n
On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote:
> On 05/28/2013 06:40 AM, Pekka Paalanen wrote:
>
> > If you really need an output scaling factor like 1.5, then you report it
> > as either 1 or 2, and do a compensating scaling in the compositor to
> > achieve 1.5. That is the best compromiz
On tis, 2013-05-28 at 17:25 -0400, Kristian Høgsberg wrote:
> On Tue, May 28, 2013 at 04:23:33PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson
> >
> > It was erronously using output->current->height in one
> > place where it should use output->hei
On tis, 2013-05-28 at 16:10 -0400, Kristian Høgsberg wrote:
> On Tue, May 28, 2013 at 04:23:32PM +0200, al...@redhat.com wrote:
> > From: Alexander Larsson
> >
> > When a window is fullscreened with DRIVER method and we succeeded
> > in changing mode we need to actua
On tor, 2013-05-23 at 15:58 -0500, Jason Ekstrand wrote:
>
> On Thu, May 23, 2013 at 3:20 PM, wrote:
> From: Alexander Larsson
>
> If an interface has any messages and its version is larger
> than 1
> then we emit a method counts
On tor, 2013-05-23 at 15:54 -0500, Jason Ekstrand wrote:
>
>
> wl_signal_get might be better here. It's more robust in (somewhat
> odd) case the user code decides to manually put a listener at the
> beginning. It's also more readable and almost just as fast (different
> by an if).
Yeah, sure,
> What if a client sets scale=0?
I guess we should forbid that, as it risks things dividing by zero.
> Maybe the scale should also be signed here? I think all sizes are
> signed, too, even though a negative size does not make sense. We seem
> to have a convention, that numbers you compute with ar
- Original Message -
> On Thu, 23 May 2013 10:55:08 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote:
> >
> >
> > > I hate to rain on the parade, but it's not going to be that simple. I
> >
- Original Message -
> From: Pekka Paalanen
>
> Default output scale of 256 makes little sense. Actually this is a type
> mismatch between wl_fixed and int, probably a leftover from when the
> scale factor was proposed as a fixed point number.
>
> Scale 256 probably causes the Window c
On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote:
> I hate to rain on the parade, but it's not going to be that simple. I
> already tried adding a field to wl_resource and, as it currently
> stands, it causes major issues. As a reminder, this is because
> wl_buffer has a wl_resource fiel
On ons, 2013-05-22 at 20:57 -0400, Kristian Høgsberg wrote:
> * Don't send out new wl_output events to clients that bind with
>version 1. For this I think we want to extend wl_resource with an
>int version; field.
Somewhat related, and I mentioned this earlier in the thread, we have a
p
On ons, 2013-05-22 at 13:01 +0300, Pekka Paalanen wrote:
> > For the record, Microsoft uses "DIP", for Device-independent-pixels, and
> > Apple uses "Points" for the non-hardware coordinates (in the app level
> > APIs).
>
> And we have no well-known equivalent in the FOSS or Linux world?
Not tha
On ons, 2013-05-22 at 11:42 +0200, Alexander Larsson wrote:
> On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote:
> > - wayland units, wu
> > - wayland pixels, wp, wpx
> > - surface units, su
> > - surface unit pixels, sux
> > - surface pixels, sp, spx
On ons, 2013-05-22 at 12:11 +0300, Pekka Paalanen wrote:
> On Wed, 22 May 2013 10:12:00 +0200
> Alexander Larsson wrote:
>
> > On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
> >
> > > We use the units of "pixels" in the surface coordinate syst
On ons, 2013-05-22 at 09:11 +0300, Pekka Paalanen wrote:
>
> > What I would like in the end is a per-output slider bar (or something of
> > that ilk) that let's the user select the interface size on that output.
> > Sure, they probably won't be able to select *any* resolution (the
> > compositor
On mån, 2013-05-20 at 13:56 -0500, Jason Ekstrand wrote:
> On Mon, May 20, 2013 at 4:00 AM, Pekka Paalanen
> wrote:
> On Thu, 16 May 2013 16:43:52 -0500
> Jason Ekstrand wrote:
>
> > The point of this soi is to allow surfaces to render the
> same size on
>
On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
> On Tue, 21 May 2013 08:35:53 -0700
> Bill Spitzak wrote:
> > This proposal does not actually restrict widget positions or line sizes,
> > since they are drawn by the client at buffer resolution. Although
>
> No, but I expect the toolki
On mån, 2013-05-20 at 09:51 +0300, Pekka Paalanen wrote:
> On Thu, 16 May 2013 15:49:35 +0200
> al...@redhat.com wrote:
>
> > From: Alexander Larsson
> >
> > This add a wl_output.done event which is send after every group
> > of events caused by some proper
On tor, 2013-05-16 at 10:05 -0500, Jason Ekstrand wrote:
> I still think we can solve this problem better if the clients, instead
> of providing some sort of pre-scaled buffer that matches the output's
> arbitrary scale factor, simply told the compositor which output they
> rendered for. Then ever
On tor, 2013-05-16 at 10:57 -0700, Bill Spitzak wrote:
> al...@redhat.com wrote:
>
> > Coordinates
> > in other parts of the protocol, like input events, relative window
> > positioning and output positioning are still in the compositor space
> > rather than the scaled space. However, input has su
On ons, 2013-05-15 at 11:13 +0300, Pekka Paalanen wrote:
> On Tue, 14 May 2013 12:26:48 +0200
> al...@redhat.com wrote:
Lots of good stuff snipped. I'll try to fix things up based on that.
Some responses below.
> > +
> > +
>
> Are you sure you really want fixed as the type?
> Integer
On tis, 2013-05-14 at 13:43 -0700, Bill Spitzak wrote:
> al...@redhat.com wrote:
>
> > +
> > +
> > +
> >
>
> Fixed is not a good idea for scaling factors. You cannot accurately
> represent values like 2/3 or 1/fixed. For an actual problem with
> scaling, if the accurate sca
On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:
> Obviously they are defined as such right now, since there is
> no scaling.
> But, the patch I proposed changes this,
>
> because otherwise we can't
> cleanly handle backwards compatibility (an
On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
>
>
> I don't think it should really be allowed to not apply the
> scaling.
> Users may want to disable scaling as it's not
one.
> On Tue, May 14, 2013 at 12:26 PM, wrote:
>
> From: Alexander Larsson
>
> This adds wl_surface_set_buffer_scale() to set the buffer
> scale of a
> surface.
>
> It is similar to set_buffer_transform that the buff
On tis, 2013-05-14 at 07:22 +0200, John Kåre Alsaker wrote:
> We may also allow scaling factors below 1. When 0 clients should draw
> using the smallest amount of pixels possible while still being
> understandable. I doubt that will be very useful and clients could
> just have 1 as a lower bound.
On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote:
>
> While this isn't a huge problem on GL-based compositors it
> will cause a problem for software compositors. Any scaling
> for that matter is a potential problem there. However, a
> factor of
On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:
>
> I don't think this will work in practice. I know for sure that
> e.g. Gtk
> is not set up to do any reasonable non-integer scaling. It
> will just
> scale up all drawing by a fractiona
On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote:
> > Clients can easily scale larger features like icons, padding
> and fonts
> > and round them to pixel sizes and draw sharp output even
> with a
> > fractional scaling factor. This allows users to
On mån, 2013-05-13 at 13:49 +0200, John Kåre Alsaker wrote:
> On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson
> wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' even
On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> For the wl_output case I suggest we add a 'done' event which signals
> that the compositor is done sending a batch of events for an wl_output
> and related extension objects (which versioned message arguments won't
> handle). This would
On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:
> The scaling factor should not have any affect of any coordinate system
> or anything else in the protocol. It should only affect the size in
> pixels of the surfaces of the clients. Clients should do any
> transformations of coordinates
On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 11:16:07 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> >
> > > Also, we need to figure out how this interacts with the pr
On mån, 2013-05-13 at 12:19 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 10:23:44 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
> >
> > >
> > > In short, I think this is far too complex for what it
On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote:
> I think we should allow fractional scale factors. Clients which only
> support integer scale factors should round the scale factor they get
> to a whole number.
I don't see how this is useful? The scaling has two main benefits:
1) It d
On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> Is there a way to bypass the scaling? When I'm using the
> mouse in
> a game, I want to know the pixel position of the pointer, with
> no
> scaling applied. I'm going to be drawing the gui at
On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
> Output scaling should be merged with the existing "buffer_transform"
> (the 8-value enumeration describing 90 degree rotations/reflections).
In effect they are parts of the same thing, yeah. I don't know if ABI
compat allows us to just chan
On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> In short, I think this is far too complex for what it achieves. In
> the case of scaling factor stuff, you can just do it with a second
> event.
I agree that what I posted have some open issues, and it was mostly
meant as a start of a
On ons, 2013-05-08 at 10:43 -0400, Todd Showalter wrote:
> On Wed, May 8, 2013 at 6:51 AM, wrote:
>
> There are problems with this.
>
> We're moving to a "HiDPI" world. With 3DTV failing in the market,
> it's looking like the TV manufacturers are going to push hard on 4K,
> and once 4K
51 matches
Mail list logo
