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.
