UPDATE: I've just realized that I have some unnecessary code in the patch, which I used for testing. I'll clean it up in the morning of UTC -4:00
Eliza On Mar 25, 2015 1:36 AM, "Eliza Guseva" <[email protected]> wrote: > Ok, great! We have lots of other bugs and oddities, so I'm sure we can >> find something :) >> > > I've started filing an application for the D-bus project. > However it turned out that for Python Foundation a patch is a requirement. > So I pushed it a little further and made an experimental fix or the layout > issue #372 for the case of stacks > > I applied it for the commit 989f0f8534ee2e34e14b8cb02920c861d053d49c > And it worked. It has an issue: the windows order is being saved, but > qtile redraws the correct order sometimes only on-click. > Maybe it's due to the method I used, maybe something else. > I used OrderedSet class, wich is under MIT license, from here: > http://code.activestate.com/recipes/576694-orderedset/ > > > I pulled the lateset commit from qtile/qtile in order to test my fix on > the newer version > I've got a message error, when tried to change layouts: > ERROR handle_KeyPress:854 KB command error nextlayout: No such command. > > Please apply my patch to 989f0f8534ee2e34e14b8cb02920c861d053d49c > > Eliza > > > On Tuesday, March 24, 2015 at 10:46:52 AM UTC-4, Tycho Andersen wrote: >> >> Hi Eliza, >> >> On Mon, Mar 23, 2015 at 08:43:06PM -0700, Eliza Guseva wrote: >> > >> > >> > Hello Tycho, >> > >> > >> > I've been reading about d-bus and there's one thing which is not quite >> > clear to me. >> > During my search I've found Python 3.3 bindings for DBUS in rather >> mature >> > versions: python-dbus 1.2.0-4 >> > Do I understand right that the issue with async could be fixed if >> > python-dbus had async support? >> > With respect to the GSoC project, I was curious, why you'd prefer a new >> > library instead of adding async support to the existing python-dbus? >> > >> >> Mostly for dependencies. In debian, if python-dbus had asyncio >> support, installing it would still pull in all of gobject/glib which >> are unnecessary. Of course, I could build it myself, but it would be >> nice to have a pure python implementation of dbus that just depended >> on asyncio and used cffi to do the C binding so that it could be pip >> installed. >> >> However, I've not spent a lot of time analyzing the existing >> python-dbus code, and if you think it would be much easier to get >> patches into python-dbus than to write a new library, then that's the >> route we should take. >> >> > >When I asked every window to print >> > > > all their attributes (from function *qtile.update_client_list()*), >> it >> > > > happened that for some reason only the first window (the one which >> goes >> > > in >> > > > the left stack) knew its attributes such as group, name and status. >> I >> > > was >> > > > curious if it is how it should be by design? >> > > >> > If I understand correctly, no, I don't think so, sounds like a bug :) >> > > >> > >> > >> > I don't know if it affects any visible behavior. Should I form a bug >> report >> > in this case? >> > >> > I think I am pretty sure about the screens-group issue: the groups with >> > indexes starting from the (number of screens +1) are located at the >> screen >> > None. >> > I think that's why windows freely jump from one group to another in my >> case. >> > So, I guess this should go to the tracker... >> >> Sounds good. >> >> > That's one approach. Another option would be to add some way to >> > > re-order things based on some state that gets passed through to qtile >> > > via an argument. >> > > >> > >> > As for the layouts. >> > I thought at some point that I could come up with the reasonable >> solution >> > in reasonable time (way before GSoC deadline) >> > But I proved to myself that I still don't know the required "guts" of >> qtile >> > and cannot really form a decent working qtile state. >> > And maybe it might require more time. I sort of want to finish it now. >> But >> > it's not an appropriate task for 3 month, so I'll continue working on >> it >> > after the hassle of applications is over. >> >> Ok, great! We have lots of other bugs and oddities, so I'm sure we can >> find something :) >> >> Tycho >> >> > >> > Eliza >> > >> > >> > >> > On Saturday, March 21, 2015 at 10:13:12 AM UTC-4, Tycho Andersen wrote: >> > > >> > > Hi Eliza, >> > > >> > > On Fri, Mar 20, 2015 at 05:35:51PM -0700, Eliza Guseva wrote: >> > > > Thanks for the clarifying comments :) >> > > > >> > > > The screens issue was related to the problem with xrandr on my >> side. >> > > > However, when I managed to get screens located side by side, I've >> got >> > > some >> > > > curious windows behavior, into which I actually need to look more. >> So >> > > I'll >> > > > skip the details. >> > > > >> > > > I looked in the layouts issue (#372). When I asked every window to >> print >> > > > all their attributes (from function *qtile.update_client_list()*), >> it >> > > > happened that for some reason only the first window (the one which >> goes >> > > in >> > > > the left stack) knew its attributes such as group, name and status. >> I >> > > was >> > > > curious if it is how it should be by design? >> > > >> > > If I understand correctly, no, I don't think so, sounds like a bug :) >> > > >> > > > Do I understand right, that this fact isn't necessary a cause for >> #372, >> > > but >> > > > that the issue is caused by the behaviour of layouts instead? >> > > > Each layout looks at th List of windows and when users move windows >> > > across >> > > > it just chooses which to show where. >> > > >> > > Yes, that sounds correct. >> > > >> > > > And at the same time windows themselves don't really know which >> stack >> > > they >> > > > are in. >> > > > So the solution is maybe in adding some information about order and >> > > stacks >> > > > to either layouts' or windows' attributes? >> > > >> > > That's one approach. Another option would be to add some way to >> > > re-order things based on some state that gets passed through to qtile >> > > via an argument. See QtileState for how we do it right now to >> remember >> > > which layouts are in which groups, and which groups are on which >> > > screens. >> > > >> > > > Actually, If I want to fix something, but got some questions, what >> is >> > > the >> > > > most appropriate way of communication: here, on the tracker or >> somewhere >> > > > else? >> > > >> > > This is good for discussion, or our IRC channel. I'd prefer we only >> > > use the tracker to discuss actual bugs (or PRs). >> > > >> > > Tycho >> > > >> > > > Eliza >> > > > >> > > > >> > > > On Thursday, March 19, 2015 at 4:36:55 PM UTC-4, Tycho Andersen >> wrote: >> > > > > >> > > > > Hi Eliza, >> > > > > >> > > > > On Thu, Mar 19, 2015 at 10:11:17AM -0700, Eliza Guseva wrote: >> > > > > > Thanks, Sean. >> > > > > > I think I would like to clarify a couple of things... >> > > > > > >> > > > > > I think I don't quite understand how multiple monitors work. >> > > > > > If I run qtile under kde I have two separate screens. There are >> some >> > > > > > issues. But they work more or less >> > > > > > If I run qtile separately I couldn't get to separate screens, >> when >> > > do >> > > > > the >> > > > > > configuration from the manual: >> > > > > > screens =[Screen(...),Screen(...)] >> > > > > > I tried also configs from example. >> > > > > >> > > > > How did you try to "get to" the separate screens? Typically, I'd >> use a >> > > > > hotkey like: >> > > > > >> > > > > Key([mod, "mod1"], "h", lazy.to_screen(0)), >> > > > > >> > > > > for this. >> > > > > >> > > > > > I was curious, if it's a normal behavior. >> > > > > > >> > > > > > In terms of the projects, I thought, that for me as for user, >> maybe >> > > the >> > > > > one >> > > > > > about layouts serialization would be the most relevant. >> > > > > > But on the other hand, for the project I thought maybe some >> other >> > > more >> > > > > > infrastructure oriented task would be of higher importance, >> like >> > > dbus >> > > > > > library for example. >> > > > > >> > > > > For me personally the dbus thing isn't a huge deal, since it is a >> > > > > relatively small line count in our code (~50 or so), and it's not >> a >> > > > > hard dependency (i.e. you can use qtile without gobject/dbus). If >> > > > > you're gauging priorities, I'd be much more interested in seeing >> the >> > > > > layout serialization work happen. Of course, that's my personal >> > > > > interest, and you should only volunteer to work on a project >> you're >> > > > > really interested in! >> > > > > >> > > > > > However, while I did quite a lot of coding (Python mainly, but >> also >> > > > > C/C++), >> > > > > > involving making complex applications from scratch. They all >> were >> > > > > research >> > > > > > oriented projects and never systems oriented. I am willing to >> learn >> > > > > > specifics, but honestly, not sure what would be a best place to >> > > start. >> > > > > > >> > > > > > Do you think, dbus library project would be an appropriate >> project >> > > for a >> > > > > > person with a research background? >> > > > > >> > > > > I think it is appropriate for someone who is sufficiently >> motivated. >> > > > > The project has the potential to have a large impact on the >> python >> > > > > community because it fills a gap that nothing else does, but >> people >> > > > > will certainly need as they move code to the event loop in the >> > > > > standard library. >> > > > > >> > > > > However, I don't think it will be easy. You'll likely be reading >> a lot >> > > > > of grotty systems/C code to get things right. For example, the >> page on >> > > > > the low level API that you'd likely be binding to says (in bold >> :): >> > > > > >> > > > > "This manual documents the low-level D-Bus C API. If you use this >> > > > > low-level API directly, you're signing up for some pain." >> > > > > >> > > > > http://dbus.freedesktop.org/doc/api/html/ >> > > > > >> > > > > The other piece is that it's likely not just a GSoC and done >> project. >> > > > > To be successful it'll need to be maintained, because projects >> won't >> > > > > bother to port code to a library that doesn't have any active >> > > > > developers willing to fix bugs. >> > > > > >> > > > > I think it's a huge opportunity to fix a problem the community >> needs >> > > > > fixed; but like all big opportunities, it'll be a lot of work >> too. >> > > > > >> > > > > Tycho >> > > > > >> > > > > > Eliza >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > Do I understand it right, that it's not particularly friendly >> with >> > > > > multip >> > > > > > >> > > > > > On Wednesday, March 18, 2015 at 10:56:25 AM UTC-4, Sean Vig >> wrote: >> > > > > > > >> > > > > > > Hi Eliza, >> > > > > > > >> > > > > > > That's great to hear that you are interested in Qtile. Since >> the >> > > most >> > > > > > > recent version (0.9.0), it is up to personal preference which >> > > version >> > > > > of >> > > > > > > Python to run. We've pushed to get Python 3 support, and >> > > personally >> > > > > since >> > > > > > > we've had the support for it, I've been running on Python 3, >> but >> > > we >> > > > > want to >> > > > > > > continue to support Python 2 until the community has moved >> beyond >> > > it. >> > > > > Let >> > > > > > > us know if you have questions moving forward. >> > > > > > > >> > > > > > > Sean >> > > > > > > >> > > > > > > On Tue, Mar 17, 2015 at 9:39 PM, Eliza Guseva < >> [email protected] >> > > > > > > <javascript:>> wrote: >> > > > > > > >> > > > > > >> Hello everyone, >> > > > > > >> >> > > > > > >> My name is Eliza. I am a graduate student in Stony Brook >> > > University. >> > > > > > >> I am a many years linux user and do a lot of Python coding >> as a >> > > part >> > > > > of >> > > > > > >> my graduate work. >> > > > > > >> >> > > > > > >> I intend to apply for GSoC and would be very interested to >> work >> > > on a >> > > > > > >> Qtile's project. >> > > > > > >> I have installed Qtile over my KDE, experimented with >> > > configurations >> > > > > and >> > > > > > >> now figuring out how I can contribute >> > > > > > >> and what would be the most useful contribution on my part. >> > > > > > >> >> > > > > > >> While I have found a couple of reproducible bugs as well as >> > > things I >> > > > > > >> would like to add, >> > > > > > >> I think I would need a couple of days to read more >> documentation >> > > and >> > > > > code >> > > > > > >> to get deeper into it. >> > > > > > >> >> > > > > > >> I've started investigating Python-3 based qtile. >> > > > > > >> With regards to this, I was curious, if there are some >> > > preferences >> > > > > over >> > > > > > >> Pythons in the project, >> > > > > > >> and if there are, which one would be better to work with? >> > > > > > >> >> > > > > > >> Regards, >> > > > > > >> Eliza >> > > > > > >> >> > > > > > >> -- >> > > > > > >> You received this message because you are subscribed to the >> > > Google >> > > > > Groups >> > > > > > >> "qtile-dev" group. >> > > > > > >> To unsubscribe from this group and stop receiving emails >> from it, >> > > > > send an >> > > > > > >> email to [email protected] <javascript:>. >> > > > > > >> For more options, visit https://groups.google.com/d/optout. >> > > > > > >> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > -- >> > > > > > You received this message because you are subscribed to the >> Google >> > > > > Groups "qtile-dev" group. >> > > > > > To unsubscribe from this group and stop receiving emails from >> it, >> > > send >> > > > > an email to [email protected] <javascript:>. >> > > > > > For more options, visit https://groups.google.com/d/optout. >> > > > > >> > > > > >> > > > >> > > > -- >> > > > You received this message because you are subscribed to the Google >> > > Groups "qtile-dev" group. >> > > > To unsubscribe from this group and stop receiving emails from it, >> send >> > > an email to [email protected] <javascript:>. >> > > > For more options, visit https://groups.google.com/d/optout. >> > > >> > > >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "qtile-dev" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- > You received this message because you are subscribed to the Google Groups > "qtile-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qtile-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
