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? >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... 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. 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.
