Re: Wayland backend design

[Ivan Vučica]

Sounds good.

Also, as a clarification: if I do the merge, I intend to do it bit by bit, giving me chance to review what is coming in.

On Tue, Dec 13, 2016, 07:17 Fred Kiefer <address@hidden> wrote:

I strongly support the merge into GNUstep, but would still suggest to remove the GUI extensions. There are two additional window flags for menus and I am almost sure that these could be handled just as well in the backend by checking other attributes on the menu window.

Fred


> Am 12.12.2016 um 23:14 schrieb Ivan Vučica <address@hidden>:
>
> Pulled, thanks.
>
> To check: Did you sign copyright assignment? If I get around to it, can I import your work on the wayland backend?
>
> On Mon, Dec 12, 2016 at 11:37 AM, Sergio L. Pascual <address@hidden> wrote:
> Hi Ivan,
>
> Sorry, I'm using Gogs as git server, and it dies from time to time
> (still better than running that monstrosity named GitLab). It should be
> up now.
>
> Sergio.
>
>
> On Sun, 2016-12-11 at 01:34 +0000, Ivan Vučica wrote:
> > Hey Sergio,
> >
> > I wanted to take a peek at this since a change in the bootloader (!)
> > seems to have weirdly interacted with nvidia's drivers and gave me
> > back the use of a framebuffer device.
> >
> > Was there any further progress here? Because the repos seem to be
> > down, do you have a copy of this code somewhere else? Shall we work
> > on upstreaming this?
> >
> > Thanks
> >
> >
> >
> > On Fri, Feb 19, 2016 at 2:29 PM Ivan Vučica <address@hidden> wrote:
> > > A very cursory look generally makes me happy (but it is indeed
> > > dirty and requires cleanup).
> > >
> > > Thank you for your work! I'm looking forward to proper review of
> > > the code (or using this code, reworking it for import). :-)
> > >
> > >
> > > On Tue, Feb 16, 2016 at 11:38 PM, Sergio L. Pascual <address@hidden
> > > g> wrote:
> > > > Sorry, wasn't able to put any work on this for the past weeks.
> > > >
> > > > I've just created a pair of repos to hold the dirty
> > > > implementation. You
> > > > can take a look there, if you're willing to deal with extreme
> > > > ugliness:
> > > >
> > > >  - https://git.sinrega.org/slp/back-dirty
> > > >  - https://git.sinrega.org/slp/gui-dirty
> > > >
> > > > I expect to be able to start the clean implementation on the next
> > > > week.
> > > >
> > > > Sergio.
> > > >
> > > > On Thu, 2016-02-11 at 01:58 +0000, Ivan Vučica wrote:
> > > > > Hello,
> > > > >
> > > > > Any updates?
> > > > >
> > > > > Having something to start hacking on would be great.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > On 25 Jan 2016, at 23:21, Ivan Vučica <address@hidden> wrote:
> > > > >
> > > > > > I'd be happy to help -- but first there's a need to have
> > > > something
> > > > > > to help on :-)
> > > > > >
> > > > > > On Sun, Jan 24, 2016, 23:27 Sergio L. Pascual <address@hidden
> > > > g>
> > > > > > wrote:
> > > > > > > In the next weeks, I'll be doing a clean implementation of
> > > > the
> > > > > > > changes,
> > > > > > > in a sane way and following the coding style. Meanwhile,
> > > > I've
> > > > > > > initiated
> > > > > > > the process to assign the copyright to the FSF.
> > > > > > >
> > > > > > > I also plan to publish the ugly, dirty code somewhere, so
> > > > you can
> > > > > > > take
> > > > > > > an early look at it.
> > > > > > >
> > > > > > > On Sun, 2016-01-17 at 19:02 +0000, Ivan Vučica wrote:
> > > > > > > > Please do let me know when you have something to review
> > > > --
> > > > > > > thanks! :)
> > > > > > > >
> > > > > > > > On Fri, Jan 15, 2016 at 6:41 PM Ivan Vučica <address@hidden
> > > > net>
> > > > > > > wrote:
> > > > > > > > > On Thu, Jan 14, 2016 at 7:04 PM Sergio L. Pascual <slp@
> > > > sinreg
> > > > > > > a.org>
> > > > > > > > > wrote:
> > > > > > > > > > On Thu, 2016-01-14 at 15:49 +0000, Ivan Vučica wrote:
> > > > > > > > > > > I think it would be worth reviewing this code. If
> > > > you
> > > > > > > agree,
> > > > > > > > > > I'd love
> > > > > > > > > > > a patch series applied on top of a particular
> > > > Subversion
> > > > > > > commit
> > > > > > > > > > > (possibly published as a series of Git commits on
> > > > top of
> > > > > > > a
> > > > > > > > > > mirror
> > > > > > > > > > > created by Gregory). Each patch should tackle one
> > > > self-
> > > > > > > > > > contained task
> > > > > > > > > > > ("git add -i" is awesome). Alternatively, each Git
> > > > branch
> > > > > > > > > > should
> > > > > > > > > > > tackle one task, and could be collapsed into a
> > > > single
> > > > > > > patch
> > > > > > > > > > (i.e.
> > > > > > > > > > > Subversion commit).
> > > > > > > > > >
> > > > > > > > > > I like the idea of linking git commits to self-
> > > > contained
> > > > > > > tasks.
> > > > > > > > > > In
> > > > > > > > > > fact, is the strategy I use for all my repos, both
> > > > personal
> > > > > > > and
> > > > > > > > > > professional (in this case, we do SCRUM, and each
> > > > commit
> > > > > > > should
> > > > > > > > > > reference a bug/task/improvement ticket).
> > > > > > > > > This is an approach I'm fine with.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Bundling a bunch of changes of a branch into a single
> > > > one
> > > > > > > doesn't
> > > > > > > > > > sound
> > > > > > > > > > as good, though. That could only mean that you have a
> > > > > > > really
> > > > > > > > > > broken
> > > > > > > > > > commit policy for your git repo, and that you need
> > > > this to
> > > > > > > make
> > > > > > > > > > some
> > > > > > > > > > sense of it ;-)
> > > > > > > > > This was mentioned having in mind the approach that
> > > > people
> > > > > > > might
> > > > > > > > > have: commit possibly broken things as you go, keep
> > > > them on a
> > > > > > > > > branch, then consider the "pull request" (with 20, 30
> > > > smaller
> > > > > > > > > commits) as the final product. For purposes of GNUstep,
> > > > > > > however,
> > > > > > > > > not a "pull request" but a "patch" should be considered
> > > > the
> > > > > > > final
> > > > > > > > > product. This means "if you commonly do pull request,
> > > > it'd be
> > > > > > > > > preferable to squash it first".
> > > > > > > > >
> > > > > > > > > Why? Two reasons:
> > > > > > > > >
> > > > > > > > > - We still use Subversion
> > > > > > > > >   - your commits will spam watchers and history with
> > > > many
> > > > > > > commit
> > > > > > > > > notifications (e.g. via email or RSS)
> > > > > > > > >   - or they will get squashed (which watchers will
> > > > probably
> > > > > > > prefer)
> > > > > > > > >
> > > > > > > > > - I would like to use Gerrit to review your changes.
> > > > > > > > >   - Gerrit has a concept of a 'change' (approximately,
> > > > one
> > > > > > > > > Subversion commit or
> > > > Github/Bitbucket/pick_code_hosting_site
> > > > > > > pull
> > > > > > > > > request)
> > > > > > > > >   - Each change track the history of the change as it
> > > > is
> > > > > > > being
> > > > > > > > > reviewed
> > > > > > > > >   - Each item in the history is called a 'patch set'
> > > > > > > > > (approximately, full diff from the base commit -- think
> > > > > > > 'squashed
> > > > > > > > > development history')
> > > > > > > > >
> > > > > > > > > So it's a different workflow than I would use for a
> > > > personal
> > > > > > > small
> > > > > > > > > project, which amounts to "record much of history so
> > > > you can
> > > > > > > > > revert! use branches to avoid breaking master!".
> > > > > > > > >
> > > > > > > > > I'd be fine with not using Gerrit to review, but we'll
> > > > still
> > > > > > > need
> > > > > > > > > to deal with Subversion, which will lose much of the
> > > > useful
> > > > > > > > > metadata anyway (e.g. when was the commit made).
> > > > > > > > >
> > > > > > > > > So I'd still like to /kindly ask/ for medium-sized
> > > > patches
> > > > > > > amenable
> > > > > > > > > to being submitted via Subversion -- or Git branches
> > > > that are
> > > > > > > > > squashable. :-)
> > > > > > > > >
> > > > > > > > > (I'm only kindly asking, because if this is not
> > > > acceptable, I
> > > > > > > don't
> > > > > > > > > want procedure to prevent something as useful as this
> > > > from
> > > > > > > coming
> > > > > > > > > in.)
> > > > > > > > >
> > > > > > > > > > That said, moving everything (repos, issue tracking,
> > > > > > > milestone
> > > > > > > > > > management and even CI) to a self-hosted Gitlab
> > > > instance
> > > > > > > (or some
> > > > > > > > > > other
> > > > > > > > > > similar, FOSS tool) would surely make the life of
> > > > both
> > > > > > > > > > maintainers and
> > > > > > > > > > contributors a lot easier. I know is somehow
> > > > inappropriate
> > > > > > > to say
> > > > > > > > > > this,
> > > > > > > > > > being a newcomer, but hey, you asked :-P
> > > > > > > > > We have a migration path to Git and it's going to be
> > > > executed
> > > > > > > Real
> > > > > > > > > Soon Now.
> > > > > > > > >
> > > > > > > > > But, let's end the discussion here to avoid the
> > > > occurrence of
> > > > > > > > > another (sadly toxic) centithread.
> > > > > > > > >
> > > > > > > > > > > Additionally -- because reviewed code is easier to
> > > > review
> > > > > > > when
> > > > > > > > > > > executed -- could you prepare setup instructions so
> > > > I can
> > > > > > > more
> > > > > > > > > > easily
> > > > > > > > > > > build and run this? My desktop is Ubuntu 14.04; my
> > > > > > > > > > understanding is
> > > > > > > > > > > that I will need to run Weston under X11 (Nvidia
> > > > drivers
> > > > > > > I use
> > > > > > > > > > are
> > > > > > > > > > > proprietary blobs; I haven't tried setting up X-
> > > > less
> > > > > > > Wayland
> > > > > > > > > > thus
> > > > > > > > > > > far).
> > > > > > > > > >
> > > > > > > > > > Weston has a variety of its own backends, so you can
> > > > run in
> > > > > > > under
> > > > > > > > > > X11,
> > > > > > > > > > directly on FB/DRM, or under another Wayland
> > > > compositor.
> > > > > > > > > >
> > > > > > > > > > To run it you'll just need to build wayland-protocol,
> > > > > > > wayland and
> > > > > > > > > > weston (the forked one). Probably, there should a
> > > > page in
> > > > > > > the
> > > > > > > > > > wiki
> > > > > > > > > > explaining this, among some description of its design
> > > > and
> > > > > > > > > > internals.
> > > > > > > > > I'm mainly requesting some tl;dr instructions to
> > > > minimize
> > > > > > > time
> > > > > > > > > it'll take me to set up a development/review
> > > > environment.
> > > > > > > > >
> > > > > > > > > I've only toyed with running Weston available under
> > > > Ubuntu
> > > > > > > 14.04,
> > > > > > > > > so I have no experience building it (my understanding
> > > > is that
> > > > > > > I'll
> > > > > > > > > need a patched version?), and I have no experience
> > > > running
> > > > > > > Wayland
> > > > > > > > > apps. So if you can get me from "empty Ubuntu homedir"
> > > > to
> > > > > > > "gnustep
> > > > > > > > > under wayland", that'd be great.
> > > > > > > > >
> > > > > > > > > (Of course, reasonable granularity of steps :-) I can
> > > > > > > hopefully
> > > > > > > > > quickly resolve some build issues as long as I have
> > > > general
> > > > > > > > > requirements and steps in front of me.)
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Have you filled copyright assignment forms with
> > > > FSF? This
> > > > > > > would
> > > > > > > > > > be
> > > > > > > > > > > necessary to import your code into GNUstep itself.
> > > > > > > > > >
> > > > > > > > > > Not yet, but I filled them in the past for other
> > > > projects
> > > > > > > (GNU
> > > > > > > > > > Hurd,
> > > > > > > > > > GNU Mach, and Glibc, I had a wild youth ;-), so this
> > > > > > > shouldn't be
> > > > > > > > > > a
> > > > > > > > > > problem.
> > > > > > > > > \o/ Excellent.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > --
> > sent from phone
> >
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev