ng wayland and
remodeling the parts that don't fit their usecase rather than doing
it all from scratch would've been better for everyone.
I guess they got hit by the NDH syndrome pretty hard, or they just
want the bragging rights for conferences when they launch it.
--
Andreas Ericsson
all, but if you have a shim you will
only have to update very, very little code to get it to work for all eternity,
and it's generally a bad idea to reimplement protocols and data structures in
a separate language.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB
always be able to change it, forcing the compositor to ignore
the program's wishes if he/she so desires.
That last bit is pretty important, actually. The "always on top" feature
from Gnome 2 was awesome. I used that a lot, and it could, with some major
annoyance
k you
> can just run "yum install weston" and simply start it afterwards to give
> it a try.
>
That's severely awesome :)
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8
last, or at the place where I tell them to. Ideally windows would
move further up and to the left if the desired window size is greater than
the area where we're supposed to draw it. That would make things behave
properly when moving from an external screen to the internal one on a
laptop.
ext, tabs usually come out as spaces in the result.
Whatever way you used, I'm sure a resend without the damage will
increase your chances of the patch being accepted.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225
of my screen. In any sane faking of the real world that plastic edge
would simply cover the shadow, so it makes perfect sense to ignore it
completely when snapping windows.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225
char * home = getenv("HOME");
> + char string[128];
Any reason you're not using either PATH_MAX or a dynamic variable here?
People with $HOME mounted on some horrifying network monster may well
have paths too long for this, and there's no real reason to
sor_type {
> WL_CURSOR_BOTTOM_LEFT,
> WL_CURSOR_BOTTOM_RIGHT,
> @@ -75,4 +79,8 @@ wl_cursor_theme_get_cursor_by_name(struct wl_cursor_theme
> *theme,
> struct wl_buffer *
> wl_cursor_image_get_buffer(struct wl_cursor_image *image);
>
> +#ifdef
-light-from-weston-on-android.html
>
That's severely cool. Awesome job :)
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol,
On 04/05/2012 12:08 PM, Jonas Ådahl wrote:
> On Thu, Apr 5, 2012 at 11:42 AM, Andreas Ericsson wrote:
>> On 04/04/2012 02:37 PM, Kristian Hoegsberg wrote:
>>> On Wed, Apr 04, 2012 at 01:51:08AM -0600, Scott Moreau wrote:
>>>> ---
>>>
>>>>
&g
e to stash the next and prev pointers, so any difference
in execution time should be microscopic, if it exists at all, and the
possibility of using the wrong one is obviously very real.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
nge
fb_id to be an int instead of an unsigned.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we sh
_notify->window);
>
> @@ -668,7 +669,7 @@ weston_wm_handle_map_notify(struct weston_wm *wm,
> xcb_generic_event_t *event)
> weston_wm_activate(wm, window, XCB_TIME_CURRENT_TIME);
> }
>
> -static const int incr_chunk_size = 64 * 1024;
> +static const unsigned int
, and in-code comments rarely go as stale as
external documents meant to describe it.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcoh
freed
> during some other dispatch callback, causing segmentation faults when
> the event loop later tries to handle an event from the freed source.
>
> Signed-off-by: Jonas Ådahl
> ---
Very nice :)
FWIW,
Acked-by: Andreas Ericsson
--
Andreas Ericsson
ll mean that much.
* Since wayland will likely have relatively few sources, it might even
be more efficient to not keep the continous table of sources, since
that one will almost certainly be prioritized by the LRU sitting cache.
Either way; There was a problew. Now it's most likely fixed.
On 03/20/2012 02:28 PM, Jonas Ådahl wrote:
> On Tue, Mar 20, 2012 at 2:22 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would run into the dreaded
>> "undefined behaviour&quo
return -1;
> +
> + loop->dispatching = 1;
> n = 0;
> for (i = 0; i< count; i++) {
> source = ep[i].data.ptr;
> - n += source->interface->dispatch(source,&ep[i]);
> + if (!source->destroy)
> +
t. We free() it
only when we run the post_dispatch_check() loop.
We also handle the case where multiple dispatchers want to remove
the same source several times by refusing to add it to the post
dispatch check list more than once.
Signed-off-by: Andreas Ericsson
---
src/even
On 03/20/2012 01:19 PM, Ander Conselvan de Oliveira wrote:
> Hi,
>
> See comments below.
>
> On 03/20/2012 12:31 PM, Andreas Ericsson wrote:
>> When a dispatch for sourceA wishes to remove sourceB and sourceB
>> has input that isn't yet processed, we would ru
ispatch_check() loop.
Signed-off-by: Andreas Ericsson
---
I actually haven't managed to build wayland yet, and since I'm stuck
with an nvidia videocard it's not likely to happen anytime in the
near future either, so this patch is, unfortunately, totally
, but I'm raising the flag anyway.
We can't just mark the source as removed when we're running dispatchers,
since we won't encounter it if it doesn't have input. Walking the list
of input events twice to mark the ones with input first is so stupid I
refuse
d,&ep, 1, timeout);
> if (count< 0)
> return -1;
> - n = 0;
> - for (i = 0; i< count; i++) {
> - source = ep[i].data.ptr;
How about just
if (!source)
continue;
here? In particular since removing a sour
e time,
that's hardly relevant. Wayland is not a key/value storage for applications
to put data in, and hidden window's can't receive events (transparent ones
can, but destroyed/hidden ones can't), so there's no data that wayland would
care about that the application can be sa
pthread_mutex_lock(&display->marshalling_mutex);
This makes no sense. If we know we're likely to crash if the thread
we're being called as isn't the same as the one that created the
display instance, we should disallow it and return an error instead
of
y awesome
programs for assisting with corefile debugging.
I also have a small and ridiculously simple profiler thing which just
takes a delta of two timeval structs which can be used to make sure
tests run in a timely manner.
The reason I find basic helpers more helpful than full framew
lay=0x25b88b0) at
> wayland-server.c:837
> #11 0x0040c3cd in main (argc=3, argv=0x7fffcecda018) at
> compositor.c:2518
>
> Just like I assumed, it is now blocking in sendmsg(). Killing clickdot,
> Weston came back to life.
>
Because sendmsg() returns
ver kicks in. Quite
a lot of companies have a 1-minute rule for engaging screensavers and
password-protecting their unlocking. Screen dimming usually doesn't
happen until the computer's been idle for at least 10 minutes though,
and it definitely doesn't make sense to dim the s
t from Reply-To munging, but even then it's
usually better to just leave it as-is and let everyone hit "reply-all"
when responding to list email.
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225
amlessly by the
toolkit used (gtk+, qt or whatever).
--
Andreas Ericsson andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we sh
31 matches
Mail list logo
