#8 X11 support 1 year, 8 months ago

Comment by ~dennwc on ~eliasnaur/gio

The move/rename of the native type (C type for EGL).

#8 X11 support 1 year, 8 months ago

Comment by ~dennwc on ~eliasnaur/gio

~eliasnaur Still busy, sorry. If you have time to apply the mentioned change, may I ask you to do it on your side? I'll jump back to it to finish XKB as soon as I can.

On Thu, 26 Sep 2019 at 14:07, Denys Smirnov denis.smirnov.91@gmail.com wrote:

Are you still working on the X11 backend?

Yes, but I was busy recently. Will make the changes in following days.

FWIW, I extracted the XKB logic to a separate file independent of Wayland. Perhaps the X11 backend can reuse the code.

This is awesome! I'll check if I can reuse it directly, or there is something else needed on X11 side.

On Thu, 26 Sep 2019 at 11:05, ~eliasnaur outgoing@sr.ht wrote:

FWIW, I extracted the XKB logic to a separate file independent of Wayland. Perhaps the X11 backend can reuse the code.

https://gioui.org/commit/51cfb4e

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/8#comment-3896

-- Denys

-- Denys

#8 X11 support 1 year, 8 months ago

Comment by ~dennwc on ~eliasnaur/gio

Are you still working on the X11 backend?

Yes, but I was busy recently. Will make the changes in following days.

FWIW, I extracted the XKB logic to a separate file independent of Wayland. Perhaps the X11 backend can reuse the code.

This is awesome! I'll check if I can reuse it directly, or there is something else needed on X11 side.

On Thu, 26 Sep 2019 at 11:05, ~eliasnaur outgoing@sr.ht wrote:

FWIW, I extracted the XKB logic to a separate file independent of Wayland. Perhaps the X11 backend can reuse the code.

https://gioui.org/commit/51cfb4e

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/8#comment-3896

-- Denys

#33 Proposal: add layout.Context 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

Sounds good, I see no harm in simplifying things. The library clearly states that API may break, so it should be OK :)

#32 Sourcehut Pain Points 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

~eliasnaur Thanks! That would help to some degree.

But still, I have no idea why you don't even want to consider Gitea/Gitlab/whatever as an option, since you haven't commented on most of the points :D

I did a bit more research on it and found a nice feature comparison table: https://docs.gitea.io/en-us/comparison/

Apparently, they plan to support creating issues by email. Same can be done for patches eventually.

Also, turned out they have a free hosted version at https://gitea.com.

#214 Provide authenticated SMTP access for sr.ht users 1 year, 9 months ago

Comment by ~dennwc on ~sircmpwn/sr.ht

Quote author here. Plus one for this feature!

#8 X11 support 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

text input is not working for me in the gophers app

~rkanchan X11 backend doesn't support keyboard input yet :)

#19 Add multiple top-level windows 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

The other backends also only support one window for now :)

That explains a few things in the code :D

#27 Using 'go run' with a different target 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

In the current X11 prototype it tries to connect to Wayland first and if connection fails from the start it falls back to X11. It's not hard to change the code to use an env to force a specific target.

I would propose to avoid build flags for this case because it's hard to predict if the app will be running with Wayland or X11 on different Linux distros upfront. The downside is that it would require both X11 and Wayland headers at build time. I guess I can also add a wayland build flag that will exclude X11 from the build completely.

It will also simplify a gradual transition from X11 to Wayland - the app will just start using the new code path automatically with no re-configuration necessary.

#19 Add multiple top-level windows 1 year, 9 months ago

Comment by ~dennwc on ~eliasnaur/gio

On Thu, 29 Aug 2019 at 21:29, ~eliasnaur outgoing@sr.ht wrote:

On Thu Aug 29, 2019 at 9:17 PM ~dennwc wrote:

Another questions to consider: how the app will know if it's running in a "multi-window OS" or not? We can probably expose some global function that app can call to know this, but I'm not sure this information is always available before creating a window (e.g. checking extensions

support, etc). So maybe return an ErrOnlyOneWindow from

app.NewWindow?

I expect a multi-window program to either not support single window systems or check runtime.GOOS or similar before proceeding. I think it's harder to image a program that changes its behaviour according to the result of the second NewWindow call.

I can imagine some kind of visual/sound editing app with a main window and small tool windows. It could fallback to rendering those tool windows inside the main one or draw a few on-screen buttons if it's an app for Android, for example.

But you are right, it's probably easier to work with a single mode, e.g. a single window if the goal is to support such diverse platforms. All make two binaries with slightly different root layouts.

Also, should we allow a rendering goroutine per window? It sounds reasonable, especially for a future (Vulkan), but needs to be considered carefully when designing internals.

What do you mean by "rendering goroutine"? If you mean the program controlled goroutine that fetches events from Window.Events, then I hope it will be up to the program to decide. It could run the windows from different goroutines or it could select on multiple window's Event channel from a single goroutine.

Yeah, sorry, forgot the immediate mode specifics. I meant the routine that processes events for each window.

To be honest, I haven't looked too deep into multi-window support and how it works from the users perceptive, hence the misunderstanding from my side. X11 backend that I've worked supports only a single window for now.

-- elias

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/19#comment-3537

-- Best regards, Denys Smirnov.