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? 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. 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? 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? 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]. For more options, visit https://groups.google.com/d/optout.
