The %m from glibc would indeed be a portability problem. However, it is already
lightly used within wayland (11 occurrences) and heavily in weston (125
occurrences). I suggest you keep them for now, then clean them all up in one
patch later - assuming the wayland community and prospective users
On 10/22/2014 02:13 AM, Marek Chalupa wrote:
What I'm wondering is what should be the behavior of wl_strtoul for
negative numbers?
strtoul silently converts them, but I don't think this is what we always
want... or is it?
-1 is a handy shortcut for strtoul to get all the bits turned on and get
Since commit 4c163b9b001bd93aaf97d7e962873a379eb90bfd, wayland-scanner
is built in top builddir instead of src, and protocol files are
generated in protocol subdir instead of src.
Protocol files generated in the new path are already properly ignored
in the toplevel gitignore file.
Signed-off-by: O
I'd prefer to see the refactor and the new feature in separate patches,
but this is pretty trivial.
I also have a slight preference for exit(EXIT_FAILURE), which is already
used somewhere else in that file - though there's also precedent for
exit(1), so you make the call. :)
I'd not seen printf'
Process a new section 'autolaunch' from weston.ini, launching all
programs given there on desktop start-up.
[Frederic Plourde: cut redundancy between do_autolaunch and panel_add_launcher]
---
clients/desktop-shell.c | 97 ++---
man/weston.ini.man |
I pushed an updated patch v3. Added test cases for overflow and also
check for negative numbers for wl_strtoul..
please review
BR
imran
On Wed, Oct 22, 2014 at 12:13 PM, Marek Chalupa wrote:
> Hi,
>
> Personally, I'd rather see these functions private (somebody has already
> mentioned that),
> b
strtol/strtoul utility functions are used extensively in
weston/wayland, and are not bug-free in their current form.
To avoid definition in weston and wayland, its wrapped
in functions with appropriate input and output checks.
Test cases are also updated.
Signed-off-by: Imran Zaman
---
src/scann
On Tue, Oct 21, 2014 at 08:21:26PM +0200, Stefanie Behme wrote:
> Hi,
>
> on last ELCE in Duesseldorf I learned that the development of libinput was
> started to handle input devices in Wayland compositors. I had a look in the
> API documentation and found that the enum "libinput_key_state" has th
Hi,
Personally, I'd rather see these functions private (somebody has already
mentioned that),
but I understand there are reasons for them to be public and maybe in the
end it will have more pros..
Anyway, I have few nitpicks and a questions - see below.
On 16 October 2014 18:11, Imran Zaman wrot
On 20.10.2014 18:13, Daniel Stone wrote:
Each to their own; I don't think it's necessarily any more complex than
split compositors, since at some point you have to deal with input
splitting anyway, and if you want both security (i.e. random users not
opening random devices) and performance (i.e.
10 matches
Mail list logo
