todo.sr.ht

Could you provide your Java version? I believe that, due to poorly maintained components in the Android toolchain, we currently depend on Java 1.8 at build time (though naturally your app runs on modern java).

#295 Material Data Table Bounty Issue 9 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

Should I make a test file?

We always appreciate tests with new features. I apologize for missing this question when I last read your comment.

I've posted my review to the mailing list here.

#254 GraphQL ticket pagination only returns a single page of results 11 days ago

Comment by ~whereswaldon on ~sircmpwn/todo.sr.ht

No change:

query {
    trackerByOwner(owner: "~eliasnaur", tracker: "gio") {
id
created
        tickets(cursor: "cursor-from-first-page") {
            results {
id
created
                submitter {
                    canonicalName
                }
            }
            cursor
        }
    }
}

Yields:

{
  "data": {
    "trackerByOwner": {
      "id": 1117,
      "created": "2019-03-30T14:54:44Z",
      "tickets": {
        "results": [],
        "cursor": null
      }
    }
  }
}

#254 GraphQL ticket pagination only returns a single page of results 11 days ago

Comment by ~whereswaldon on ~sircmpwn/todo.sr.ht

Adding the created field for both the tracker and the tickets didn't change the behavior:

query {
    trackerByOwner(owner: "~eliasnaur", tracker: "gio") {
        created
        tickets(cursor: "cursor-from-page-1") {
            results {
                created
                submitter {
                    canonicalName
                }
            }
            cursor
        }
    }
}

Results:

{
  "data": {
    "trackerByOwner": {
      "created": "2019-03-30T14:54:44Z",
      "tickets": {
        "results": [],
        "cursor": null
      }
    }
  }
}

#318 Request a decoration-less Window 11 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

the actions that can be performed on the window are harcoded (minimize/maximize/close). Would more be useful like (fullscreen/move)?

I would say, rather, that making them configurable would be useful. For instance, accepting a variadic list of actions. Seems like it would add complexity though. Maybe that can wait until after the initial implementation?

the actions are currrently laid out via clip.Paths to avoid a dependency on the icons package, which does not have min/max icons anyway. Any other valid approach?

I suppose we could draw them as images, but that's ugly. I think raw paths is a fine approach. Alacritty draws its own decorations as simple paths on Wayland, and that works for me. I don't think we need anything super fancy here.

when un-maximizing a window, it needs to be repositionned to where it was. Would adding app.Position Option be OK?

Seems reasonable to me, but we'll see what ~eliasnaur thinks.

~pierrec, could you provide an example of how you would use the decorations (for instance, a modified gioui.org/example/hello)? There are some questions I'd like to resolve around that:

What is the default wayland behavior? Do we draw these decorations for a window automatically?

How do we make it easy to use these decorations on Wayland (where they are necessary) without making an app that needs to support other platforms really complex? I'd like to avoid making apps use build constraints add/remove the decorations if we can. For instance, if the decorations had a way to detect whether the window was already decorated so that they could skip drawing themselves.

#254 GraphQL ticket pagination only returns a single page of results 14 days ago

Ticket created by ~whereswaldon on ~sircmpwn/todo.sr.ht

I'm having trouble paging through tickets with the GraphQL API on todo.sr.ht. Using this query:
query ($cursor: Cursor) {
    trackerByOwner(owner: "~eliasnaur", tracker: "gio") {
        tickets(cursor: $cursor) {
            results {
                submitter {
                    canonicalName
                }
            }
            cursor
        }
    }
}
I get the first page of results just fine, but supplying the cursor to the second invocation results in an empty response every time:
{
  "data": {
    "trackerByOwner": {
      "tickets": {
        "results": [],
        "cursor": null
      }
    }
  }
}
I've tried using the GraphQL playground, curl, and my own program, and I get consistent results in all of them. I also tried hard-coding the cursor into the second query to check for string processing issues, but that didn't help.

I know this tracker has hundreds of tickets, so it isn't just that there are only 25 results. I also tried this on other trackers with the same single page of results.

You should be able to test this for yourself on the playground by running the query I used above and then copying the cursor from its response back into the query:

https://todo.sr.ht/graphql

#309 Load default system fonts 17 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

~pierrec, The go-text project is discussing this issue now if you'd like to provide your insights: https://github.com/go-text/typesetting/issues/17

#295 Material Data Table Bounty Issue 21 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

Okay, I've had a chance to review the latest code in depth.

But there is one change that I would rather undo. The separation of the persistant state from the layout info. I belive it is counter-productive, has worse performance, and is difficult to understand for the user. I will come back with more info on this.

Unless I misunderstand you, this is an objection to Gio's current paradigm for designing layouts and widgets. While that is a fair thing to object to, this is the wrong place to advocate for a change. We should discuss the design of Gio's widgets as a whole elsewhere (another issue, perhaps?), and constrain this discussion to building a widget that matches the design of the others.

We're reaching a point where it would be useful to review the code in a medium that allows me to comment on individual lines. Would you be willing to submit your changes either as a patchset on the mailing list or as a PR to our GitHub mirror?

My feedback on the current code:

Do you object to the creation of a material.TableStyle to handle the table-specific use-cases? I discussed the idea in my previous review.

I don't think that we should accept the AnchorStrategy as a parameter to the material.Grid constructor. We can let it assume the default value and allow the user to override it.

I noticed a bug in the placement of header cells if you change the AnchorStrategy in the demo to Occupy. If you make the window narrower than the table and scroll all the way to the right, the headers will mis-align from the table cells by the width of the scrollbar track.

It's looking very good on the whole. I'd like it in PR or patchset form so that we can discuss some minor implementation details inline rather than tediously linking to them from here.

Thank you for your patience in working on this, and happy new year!

#295 Material Data Table Bounty Issue 21 days ago

Comment by ~whereswaldon on ~eliasnaur/gio

Hey ~jkvatne, I apologize again for the latency on my part. The holidays have thoroughly disrupted my routine. I plan to give this a review tomorrow morning. I haven't forgotten!