Moving Forward -- The Future of Qtile
Derek Payton
As you are all no doubt aware, development on qtile has been somewhat
stalled lately due to cortesi's busy schedule. Several of us on IRC
have been discussing on how to best kickstart development of the
project, and I was apparently volunteered to raise the issue on the
mailing list. ;)
My personal belief is that, we should have a small group of trusted
collaborators -- even one person -- to merge pull requests, respond to
bug reports, and generally help drive development of the project. The
biggest issue with this is finding someone(s) with the ability,
interest, and time to do so. I guess you could consider this a request
for volunteers.
I also feel that a separate qtile organization on Github should be
setup to house the official repository. I have taken the liberty of
setting this up and have added cortesi as an owner.
https://github.com/qtile
Finally, I want to point out that someone has put a lot of effort in
recent months to pull in a ton of external commits. It would be great
if these could be vetted and merged into master. If you're interested
in the aforementioned request for volunteers, this would be an
excellent place to start.
https://github.com/paradoxxxzero/qtile
That's about all I have at the moment. I've loved using qtile for the
past year, and want to see it succeed. I'd love to know what everyone
else, especially cortesi, thinks.
Thanks!
--Derek
Aldo Cortesi
I agree with this entirely - at the moment, I'm absolutely hectically busy on other things, and Qtile is sadly coming second to some other big commitments. We need to get a few trusted people together to help take the project forward. I would like to see folks like Matt Harrison and Paul Colomiets involved, if they have the time.
There are also a few other things that need to be done to move the project in a direction that welcomes contributions from a wider set of people. When Qtile was small, using my own document generator and unit test library was fine, but these projects are pretty personal to me and aren't particularly welcoming to contributors. I suggest moving to Sphinx and nose, both good, solid projects with wide penetration.
> I also feel that a separate qtile organization on Github should be
> setup to house the official repository. I have taken the liberty of
> setting this up and have added cortesi as an owner.
>
> https://github.com/qtile
I officially bless this move.
> Finally, I want to point out that someone has put a lot of effort in
> recent months to pull in a ton of external commits. It would be great
> if these could be vetted and merged into master. If you're interested
> in the aforementioned request for volunteers, this would be an
> excellent place to start.
>
> https://github.com/paradoxxxzero/qtile
He's done great work - I've got his stuff on my desktop for testing, and I was preparing to pull his collation of patches wholesale. As usual, however, something has come up, and now I'm traveling for two weeks so I won't get to it until the end of the month.
> That's about all I have at the moment. I've loved using qtile for the
> past year, and want to see it succeed. I'd love to know what everyone
> else, especially cortesi, thinks.
I think this is the right move. I'd like to see things solidify a bit, and have some more people on board officially before changing the webpage to reflect these moves, though.
Cheers,
Aldo
--
Aldo Cortesi
blog: http://corte.si
twitter: @cortesi
work: www.nullcube.com
+64 210 718 900
Roger Duran
I totally agree with this changes, we need someone to merge commits and keep the project alive, and a github organization, with a trusted group of contributors, seems the best choice.
I'll try to be active as i can in the future, i already have some uncommited code that need to unbreak and some ideas i really want to do, also i have to check the status of qtile and dependencies in archlinux aur packages.
Roger Durán
Tycho Andersen
> Hi everyone,
>
> As you are all no doubt aware, development on qtile has been somewhat
> stalled lately due to cortesi's busy schedule. Several of us on IRC
> have been discussing on how to best kickstart development of the
> project, and I was apparently volunteered to raise the issue on the
> mailing list. ;)
>
> My personal belief is that, we should have a small group of trusted
> collaborators -- even one person -- to merge pull requests, respond to
> bug reports, and generally help drive development of the project. The
> biggest issue with this is finding someone(s) with the ability,
> interest, and time to do so. I guess you could consider this a request
> for volunteers.
I'd be happy to. Also - is there some canonical place for xpyb-ng? I
fixed the build system, and it would be nice to get that fix merged
into wherever people are getting it from.
> I also feel that a separate qtile organization on Github should be
> setup to house the official repository. I have taken the liberty of
> setting this up and have added cortesi as an owner.
>
> https://github.com/qtile
>
> Finally, I want to point out that someone has put a lot of effort in
> recent months to pull in a ton of external commits. It would be great
> if these could be vetted and merged into master. If you're interested
> in the aforementioned request for volunteers, this would be an
> excellent place to start.
>
> https://github.com/paradoxxxzero/qtile
Cool! I didn't know about this :-)
\t
Craig Barnes
> You received this message because you are subscribed to the Google Groups "qtile-dev" group.
> To post to this group, send an email to qtil...@googlegroups.com.
> To unsubscribe from this group, send email to qtile-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/qtile-dev?hl=en-GB.
>
Hi All,
I am happy to help out where I can, and I have started testing
paradoxxxzero's fork. We should probably identify a central
collaboration space for issues / wiki etc.
I suggest we continue with Aldo's issue and wiki for now, unless
anyone has a better idea?
I'm glad to see activity on Qtile again, its been a while.
Craig
--
() ascii ribbon campaign - against html mail
/\
Derek Payton
cortesi/qtile. If the qtile/qtile is to become the canonical home of
the project, we should probably nuke that fork and move cortesi/qtile
to qtile/qtile. This way we don't lose existing pull requests and bug
reports. Cortesi would then need to fork qtile/qtile sso that existing
git checkouts don't break.
instructions detailed here: http://help.github.com/move-a-repo/
Cortesi, would you be open to this?
> I'd be happy to. Also - is there some canonical place for xpyb-ng? I
> fixed the build system, and it would be nice to get that fix merged
> into wherever people are getting it from.
I would say let's fork it to the qtile org on github and point people
there for while we wait for it to be merged upstream.
Derek
Tycho Andersen
>
> > I'd be happy to. Also - is there some canonical place for xpyb-ng? I
> > fixed the build system, and it would be nice to get that fix merged
> > into wherever people are getting it from.
>
> I would say let's fork it to the qtile org on github and point people
> there for while we wait for it to be merged upstream.
That's an interesting point: there are a number of changes qtile devs
have made (including mine) that haven't been merged upstream. Has
anyone tried? http://cgit.freedesktop.org/xcb/xpyb/ says the last
commit was 13 months ago.
\t
Craig Barnes
documented in the qtile docs source (not published to the site).
Aaron
To go with the plan of moving Qtile forward I am pushing for a real look
into documentation.
As such - I have started adding resources to my distro of choice's wiki
(Arch). May I suggest you do similar? What other plans are there with
documentation? I heard Sphinx was an idea.
I propose something along the lines of:
Installation (for whichever distros), there are a lot of arch users on
the IRC channel, so maybe we'll be covered. But I know that a couple of
Gentoo users have been having trouble, so maybe we could look into that?
Customization, we need to show what's available without digging through
the source. Many times I've looked at someone else's config.py and I've
seen some real gems that I could add to my own. Whilst this is cool - it
shouldn't be like this.
Cortesi has some *great* documentation for the first day or so of using
qtile, but I feel that this could really be added to.
Thoughts?
Derek Payton
> (Arch). May I suggest you do similar? What other plans are there with
> documentation? I heard Sphinx was an idea.
I'm absolutely +1 on Sphynx. Since Cortesi also mentioned it, I'm
committing myself to create a sphynx-docs branch this weekend to get
the ball rolling on this, and will put the results on readthedocs.org.
My hope is that, with time an a little TLC, the documentation will
become the site for Qtile (à la http://python-requests.org/)
Derek
Paul Colomiets
On Fri, Feb 10, 2012 at 7:17 AM, Aldo Cortesi <al...@nullcube.com> wrote:
> Hi Folks,
>
> I agree with this entirely - at the moment, I'm absolutely hectically busy on other things, and Qtile is sadly coming second to some other big commitments. We need to get a few trusted people together to help take the project forward. I would like to see folks like Matt Harrison and Paul Colomiets involved, if they have the time.
I'd be glad to do that. But I'm unhappy to invest time in qtile until
it's annoying memory leak will be fixed.
> Also - is there some canonical place for xpyb-ng?
I believe it's:
https://github.com/dequis/xpyb-ng
But it seems to be inactive too
--
Paul
Derek Payton
to AeroNotix and cyrus1 on IRC for contributing) and put them on
readthedocs:
This is currently pulling from my repo, but we can switch it whenever
we get the qtile organization migration finalized.
https://github.com/dmpayton/qtile/tree/sphinx-docs/docs
It still needs some work, particularly the installation docs and
auto-generating all the confobj bits in the configuration sections.
Derek Payton
http://dmpayton.com
Derek Payton
Many things have been discussed over various mailing list posts and
IRC over the past couple weeks, so I'm writing this to outline the
next steps I think we should take to take to get things moving
forward.
The first thing we need to do is get the official qtile repo squared
away. I had created this as a fork of Cortesi's repo, and it does not
include any of the pull requests and bug reports that have been
submitted. Since we probably want to preserve those, I suggest
coordinating with Cortesi and proceeding as follows:
1. Delete the qtile/qtile fork -- Nothing has been done here, so
nothing will be lost
2. Move cortesi/qtile to qtile/qtile per these instructions:
http://help.github.com/move-a-repo/
3. Cortesi will need to fork qtile/qtile to cortesi/qtile so that
existing checkouts in the wild will still point to a valid repo
This will make qtile/qtile the new official home of the project.
Once this is complete, we can start vetting paradoxxxzero's fork and
merge those changes into master.
In the mean time, I will continue working on getting all of the
documentation ported to Sphinx. As always, contributions are welcome
and encouraged.
http://qtile.readthedocs.org/
https://github.com/dmpayton/qtile/tree/sphinx-docs/docs
Once the docs have been flushed out, they can be merged into master
and I will update readthedocs to point to the official master
repository on Github. With Cortesi's blessing, we can also point
qtile.org directly to readthedocs (though I don't expect this will
happen for some time).
Next, since xpyb-ng has been inactive for quite some time, I have
forked it to the qtile organization on Github:
https://github.com/qtile/xpyb-ng
This will allow us to address certain issues that some have come
across (memory leaks, broken build process). If you have a fix, please
issue a pull request.
Finally, it has been mentioned that there should be a separate
project, e.g. qtile-contrib, to house widgets and layouts that should
live outside of core. There's no concrete plan for this yet, but
please don't hesitate to speak up if you have any suggestions. If we
decide to go through with this (I am personally +1 on the idea), I
suspect that it will be a somewhat larger undertaking, and we will
need to have discussions to decide what remains in core and what gets
bumped to contrib.
I'm looking forward to feedback.
Thanks!
--Derek
On Feb 14, 2:12 pm, Derek Payton <derek.pay...@gmail.com> wrote:
> I have taken an initial stab at porting the docs to Sphinx (shout out
> to AeroNotix and cyrus1 on IRC for contributing) and put them on
> readthedocs:
>
> http://qtile.readthedocs.org/
>
> This is currently pulling from my repo, but we can switch it whenever
> we get the qtile organization migration finalized.
>
> https://github.com/dmpayton/qtile/tree/sphinx-docs/docs
>
> It still needs some work, particularly the installation docs and
> auto-generating all the confobj bits in the configuration sections.
>
>
>
>
>
>
>
> On Mon, Feb 13, 2012 at 4:32 PM, Paul Colomiets <p...@colomiets.name> wrote:
> > Hi,
>
Anshuman Bhaduri
module). Would be nice to see the Qtile bar and its widgets moved out
to contrib, along with a few of the layouts maybe, leaving a minimal
window manager codebase. I feel the bar doesn't quite belong in the
same space as the window manager.
On Feb 23, 2:10 pm, Derek Payton <derek.pay...@gmail.com> wrote:
> Hi folks,
>
> Many things have been discussed over various mailing list posts and
> IRC over the past couple weeks, so I'm writing this to outline the
> next steps I think we should take to take to get things moving
> forward.
>
> The first thing we need to do is get the official qtile repo squared
> away. I had created this as a fork of Cortesi's repo, and it does not
> include any of the pull requests and bug reports that have been
> submitted. Since we probably want to preserve those, I suggest
> coordinating with Cortesi and proceeding as follows:
>
> 1. Delete the qtile/qtile fork -- Nothing has been done here, so
> nothing will be lost
> 2. Move cortesi/qtile to qtile/qtile per these instructions:http://help.github.com/move-a-repo/
> 3. Cortesi will need to fork qtile/qtile to cortesi/qtile so that
> existing checkouts in the wild will still point to a valid repo
>
> This will make qtile/qtile the new official home of the project.
>
> Once this is complete, we can start vetting paradoxxxzero's fork and
> merge those changes into master.
>
> In the mean time, I will continue working on getting all of the
> documentation ported to Sphinx. As always, contributions are welcome
> and encouraged.
>
Anshuman Bhaduri
Paul Colomiets
On Fri, Feb 24, 2012 at 4:19 AM, Anshuman Bhaduri
<anshuman...@gmail.com> wrote:
> I'm +1 on the qtile-contrib idea too (separate repository/separate module).
> Would be nice to see the Qtile bar and its widgets moved out to contrib,
> along with a few of the layouts maybe, leaving a minimal window manager
> codebase. I feel the bar doesn't quite belong in the same space as the
> window manager.
>
Derek, Anshuman, I think you are overestimating size of qtile code
base and community. Qtile codebase is 14 000 lines of code, while
widgets have 1700 and layourts have 2000 lines of code. We have 6
layouts (is this a big number?) and about 15 widgets (isn't a big
either). I don't see what
you are trying to optimize here. And I think that splitting qtile repo
into two ones will lead to a lot of problems:
1. You need to synchornize versions of both when installing
2. You need to test qtile-contrib when hacking on qtile anyway
3. You need to manage pull requests and issues that go into wrong repository
.. and so on.
So at current stage, where we don't have a maintainer even for a
single project, we should not invent additional problems.
If someone want to contribute 10th of layouts and zillions of widgets,
create a repository named my-qtile-widgets, put stuff there and
volunteer to maintain it. Widgets and layouts are just imported
classes so you can import them from any module not only something
named qtile-contrib.
--
Paul
Tycho Andersen
I agree with Paul here; at least right now, a qtile-contrib repo
containing widgets and layouts would be more work than it's worth.
Perhaps at some point in the future when we have more (and
specialized) layouts and widgets it will make sense.
I could however see such a repo containing user submitted configs or
scripts (basically, a replacement for and beefed up version of the
examples/ directory). -contrib may or may not be the right name for
it, though.
\t
paradoxxxzero
Sorry for the late reply, I enjoy hacking on qtile code when I have
some spare time in my hands but I'm quite busy too.
I will be very happy to see my fork merged in master and to see this
project move forward.
As far as I remember my fork adds the following things:
- Merged most of qtile forks and integrated them (includes pango
markup in widgets, new widgets, new layouts)
- Ported from unmaintained test framework pry to nose
- Huge code clean up for pep8 compliance
- Included a dbus notification daemon + widget
- Fixed notification popup position in dual screen mode
- Fixed ratiotile in dual screen
- Improved mpd widget (use of pango markup to display song position
with text color) (still makes qtile hang when mpd server dies though)
- Implemented logging with python logging module
- Added a pseudo session manager to avoid X being killed by startx on
qtile crash and tries to restart it several times (launch qtile-
session instead of qtile)
- Promoted dynamic groups as a core feature
- Many little bugfix / enhancements
I use it daily at work and at home and it's quite stable but I think
it still requires more testing so don't hesitate to checkout my
branch.
Cheers
--
Florian Mounier
Aaron
Nice to finally hear from you!
I think a good 'next step' is to pick-out (or have volunteers) for
bugtesting your branch (I know a few users have already been testing it
for a couple of weeks) then we can clearly say to cortesi that the
paradoxxxzero branch is what we what merging and then to have control
handed over to the Qtile group branch.
I'll pull from your repo tonight and go through with people in the IRC
channel on who else will join in testing. I urge you to join us in the
IRC paradox, there is often talk of your branch.
On the contrib point, I think it's a GREAT idea. I envision a situation
where there are pull requests for layout and widgets for tiny little
status bar things. It'll be the android store or something. I think a
contrib branch specifically for user-added config.py's, widgets and
layouts could go a long way to singling out the nice widgets that people
have made (lol, crash me widget, paradox).
Regards,
Aaron
Paul Colomiets
On Fri, Feb 24, 2012 at 6:04 PM, paradoxxxzero <paradox...@gmail.com> wrote:
> Hi everybody,
> I will be very happy to see my fork merged in master and to see this
> project move forward.
>
Thanks for the code.
> - Added a pseudo session manager to avoid X being killed by startx on
> qtile crash and tries to restart it several times (launch qtile-
> session instead of qtile)
I think the easier way to restart is execute `cmd_restart` inside
`errorHandler`, as most qtile crashes are just python exceptions.
--
Paul