On Wed, Nov 30 2022 at 08:01:10 PM +00:00:00, Jessica Clarke 
<jrtc27@jrtc27.com> wrote:
> The trouble is if libseat.h includes anything then the extern “C” 
> applies to that too, which may break things if they end up pulling in 
> a header that makes use of C++ things when compiling for C++

extern "C" only changes linkage, which for anything imported by C 
should also be C - otherwise things break/won't link at all.

If libraries worked differently when included in C compared to in C++ 
with C linkage, then I imagine we would have big issues whenever anyone 
tried to interop between C++ and C...

If you find or hit such an issue, please do share it.

On Wed, Nov 30 2022 at 07:43:32 PM +00:00:00, Jessica Clarke 
<jrtc27@jrtc27.com> wrote:
> The dam-subtree drivers are used for various Arm-based SoCs, though I 
> think the Panfrost GPU driver might be the only one where you’d 
> actually be able to do more than get a video console (what we’re 
> using). Intel/AMD/Nvidia are still in drm-kmod and as far as I know 
> haven’t changed behaviour.

Fair enough, just curious. :)

> I see; is it better to separate out the two #defines so (presumably) 
> it won’t enforce aligning them, or should I align them as suggested 
> by the diff?

On Tue, Nov 22 2022 at 05:44:44 AM +00:00:00, ~jrtc27 
<jrtc27@git.sr.ht> wrote:
> +#ifdef __cplusplus
> +extern "C" {
> +#endif

So far I have done the same as we do in wlroots: libseat is a C 
library, and therefore doesn't have C++ compiler directives in it.

The reasoning is that it seems illogical to make C libraries carry C++ 
code/directives around, just like we don't carry Rust, Zig, D or any 
other language-specific code/directives. If the problem is that the 
needed C++ compiler directives are too ugly, then it makes even less 
sense that C libraries should be forced to carry around another

Ah, is this something new or did I just completely miss it when working 
on FreeBSD?

CI on mailing list patches was down for a moment, but here is a manual 
rerun on alpine: https://builds.sr.ht/~kennylevinsen/job/895142 - fails 
on check-format.

On Wed, Nov 23 2022 at 02:12:42 AM +00:00:00, ~jrtc27 
<jrtc27@git.sr.ht> wrote:
> +#ifdef __FreeBSD__
> +	/* Some drivers have /dev/dri/X symlinked to /dev/drm/X */
> +	if (STR_HAS_PREFIX("/dev/drm/", path))
> +		return 1;
> +#endif

Applied with the minor style change applied, thanks!

... better late than never.

Applied, thanks!

On Tue, Nov 22 2022 at 01:21:51 PM -08:00:00, ~lechner 
<lechner@git.sr.ht> wrote:
> +            // Change working directory
> +            match env::set_current_dir(home) {
> +                Ok(_) => {},
> +                Err(e) => { eprintln!("unable to set working 
> directory: {}", e); }
> +            };

cargo fmt is a little upset here.

When you have a match where you only want one "arm" (in our case, for 
Err), a simpler way is to use `if let`, as seen in `fn main` at the 
bottom of this file. If you are okay with it, I can add that slight

On Tue, Nov 22 2022 at 01:21:51 PM -08:00:00, ~lechner 
<lechner@git.sr.ht> wrote:
> +            // Change working directory
> +            let pwd = match env::set_current_dir(home) {
> +                Ok(_) => home,
> +                Err(_) => {
> +                    env::set_current_dir("/")
> +                        .map_err(|e| format!("unable to set working 
> directory: {}", e))?;

Once we have entered the child after fork(2), we must not return. 
Instead we should either successfully exec the new process, or exit 
with an error. We have so far used `expect` and `unwrap` to just panic 
if there is an error.

Oh, hah, I was mixing things up. I reading too quickly and assumed a 
time question had to be for wlsunset.

It wouldn't be hard to make the clock in gtkgreet configurable. The 
snprintf in gtkgreet_update_clocks should be replaced with strftime, 
and the formatter set by the configuration parameter or from locale...

On Sat, Nov 12 2022 at 08:11:08 PM -08:00:00, Yavor Kolev 
<yavornkolev@gmail.com> wrote:
> Hello! I use 12 hour time, and was wondering if it could be added as a
> config option? Thanks!

Hmm, I do not think that this is worthwhile to implement.

It is far less work to mentally convert 12-hour to true 24-hour time 
than it is to add explicit support for parsing both (extra flags? try 
in order? locale based?), especially as the configured value is rarely 
changed.

(Sun-tracking is also the primary mode of operation, where time is not 
specified at all.)