Linux progress, how can I help? about druid HOT 8 CLOSED

An official downstream branch would help aggregate contributions and avoid a situation with multiple competing forks. It might also help with directing new contributors to the right place. There is still some work and cleanup to be done before the gtk fork is ready for that.

This weekend I'm wrapping my head around the WinHandler/WinCtx changes and I'll give it a shot at implementing them.

I have some time available in the next few weeks, I'll keep an eye on upstream changes and try to keep up in the gtk fork.

from druid.

I agree that the linux landscape with x11 and wayland adds complexity and that eventually a linux version should not depend on gtk.

Today I've been tinkering with the gtk fork to get a feel for the druid code base. All examples compile and run except for ext_event. You can find the code at my fork in the gtk branch.

I'm fairly new to rust so I don't think I'm the right person for an "owner" role yet. But I'm willing to spend some time in the coming weeks/months to keeping the gtk fork up to date and maybe experiment a bit with x11 or wayland.

from druid.

Can we close this issue now since #151 has landed?

from druid.

There's a lot of interest in Linux. I've expressed a call to action for an owner of the Linux port, but this is a pretty big commitment.

As I said in this Zulip thread:

So I should probably write this in a roadmap somewhere, but here's the deal, and why I have been so squirrelly about this: after I get back from Europe (so mid-June to mid-July) I plan to do a sprint to get UI basics in place: menus, input events nailed down, proper scrolling, multiple windows, file dialogs, incremental present, etc. A lot of that but not all of it is at the shell level. In any case, during that time I'm going to want to be moving fast and breaking stuff.
If somebody wants to commit to keeping Linux in sync, then I'm happy for that to be in-tree. If that doesn't happen, then it's best managed as a downstream fork as I described a bit above. After that sprint, then the coordination issues will be a lot easier, and I'll be much more open to bringing Linux in-tree, even if there's a bunch of stuff that seems like it will need rework later (I think ultimately we don't want a dep on gtk and want everything to be native, but I won't block on that). Also, my thinking is that during the druid sprint, we're not doing a massive amount on the Runebender app, as we'll also be sorting out spline and interpolation math.

As to the question of whether or not to depend on gtk, I think its clear that in the long term we do not want to. But in the shorter term it could be very useful, as otherwise we'd have to write widgets for menus and file pickers and so on, which is considerable work.

This is basically one of the reasons I've been asking for an "owner" role, as somebody who understands the implications needs to be making these decisions and guiding the implementation work. I wish I had the bandwidth, but right now I'm overcommitted, so it has to be on the back burner until somebody steps forward. It's possible ownership could be done as a collaboration between people chipping in, and I'm open to that if it works out. In any case, this issue is a great place for discussion, and I'm happy for any help!

from druid.

I'm glad someone raised the question, as I really was looking forward seeing and helping a linux port progress. I absolutely understand that linux is not as straight forward as windows or mac, due to its fragmented ecosystem, two different display servers to cover and winit not being an option:

The druid-win-shell layer is primarily an abstraction for displaying a window and receiving events. As such, it is an alternative to winit.

Furthermore the BSDs are also able to run X11 and wayland so the a "linux" platform may not be the appropriate name for it.

I would propose to rather have a "x11" and a "wayland" platform than a "unix" platform for the following reasons:

• both display servers use different primitives and concepts
• a single platform for both display managers would require another level of abstraction which brings another level of complexity
• do one thing and do it proper
• x11 users won't be doing much wayland related stuff and the other way round (bold assumption )

I would happily participate in the discussion to get this started and start tinkering once fundamental questions are out of the way.

from druid.

My personal hunch is that using gtk is a good move in the near-term, and if druid eventually matures into a major tool we can revisit.

from druid.

maybe experiment a bit with x11 or wayland

if you go for x11, this could be a head start
its a bare bone platform implementation which compiles on linux running x11
and runs in to a panic on WindowBuilder::build()

from druid.

Most development in recent weeks has been on the muggle branch, not master. That'll change as soon as #94 lands. I don't think that invalidates the existing work, but there are a few more things to fix, such as the migration from WinHandle to WinCtx, details of mouse and key events, and stuff like setting the cursor (which is not totally settled, especially on macOS).

I'm really happy to see this work, and if there's a branch that looks good I'm willing to designate it an official downstream branch. My main hesitation is blocking changes to master on Linux support, as we're finding that supporting two platforms is already plenty of a challenge. I expect the changes at the very lowest level will start stabilizing before long, but unfortunately not very soon. Coming up soon we've still got multiple windows, pop-up menus, and some related platform stuff.

from druid.