[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#1229 - Tag "index" is not handled properly User who did this - Uli Schlachter (psychon) Reason for closing: Fixed Additional comments about closing: commit 45ad4459f2e6bab737e4e93009fd4dff9f4a546b Author: Emmanuel Lepage Vallee Date: Sat Nov 1 18:46:06 2014 -0400 tag: Improve tag property::index support (FS#1229) * Move the "index" setting burden to individual functions instead of gettags(). * Add some properties earlier so the signal hooks will be called with valid data. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Emmanuel Lepage Vallee (Elv13) -- The "screen" property have simmilar issues. Some signal are emited before it is set, creating a zone where the tag is manipulated by callback, but have no screen. Maybe hacking tag.add to make sure tag is set first (and to something else than nil) will ne necessary. Some other people want tags to have no screen (xmonad / ion3 users) and move from screen to screen as needed. I am not sure if it is such a good idea. I prefer a "frame" concept instead. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment4063 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Uli Schlachter (psychon) -- > > If you want to reintroduce t.screen, what should happen to clients which > > are on different screen than their tag? > Print a big fat red error, this can only be a bug, it already produce > unwanted (and unwantable) behavior when it happen. Do you know how we move clients to another screen? Something assigns a new value to c.screen, this emits property::screen and awful.tag has its withcurrent connected to that signal. From the C code's POV, we would have to print a big red warning when c.screen gets set and before lua cleans things up. So this doesn't really work. > > I can't see the point of a *read-only* index property that is managed in C. > > Maybe the lua side should be able to keep "persistent" filtered taglist. > Maybe it is just a better idea than what this issue propose. Feel free to > close it if you agree, if you do, I will write the "persistent filtered tag > list" to feed whatever widgets will be in front of it. The bug is real, but I > forgot about the filtered tag list use case and a global index wont cover it. > Better dropping the whole index thing instead of fixing it. > > This also apply to awful.tag.byidx and the likes, they also don't cover the > filtered list use case, so they should be deprecated and eventually renamed > to something else. The users should query that persistent list entity instead > of the global one. I am still not really sure what this issue proposes, so I can't really say what a persistent(?) filtered(?) taglist would do differently. The reason we have this index thing is so that lua can change the order of tags. The C code will always return tags in the order in which they were created. For clients we have c:swap() to change their order, but that is equally ugly... -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment3890 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Emmanuel Lepage Vallee (Elv13) -- I think the problem is that we are coupling concepts that are incompatible. My original proposition was to merge index back into the core, but that wont work. Keeping it as a global magic into awful.tag also wont work, because it doesn't support filter functions. So, if we can't use the core and can't use awful.tag to fix this issue, we have to introduce a new way of keeping a tag list (as in a list of tags, not the widget called taglist). So I propose an object that will keep track of a list of tag. An object that will take care of setting properties like "urgent" that are currently very ugly and have an accessor function that will return the index _relative it itself_. It could use the tag property table to cache it or use a weak table. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment3891 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Emmanuel Lepage Vallee (Elv13) -- > If you want to reintroduce t.screen, what should happen to clients which are > on different screen than their tag? Print a big fat red error, this can only be a bug, it already produce unwanted (and unwantable) behavior when it happen. > Oh and how would we map tags to _NET_WM_DESKTOPS? First all tags of the first > screen, then the second screen etc? Well, it will never map 1-1, so I guess it would use the _NET_WM_DESKTOPS as index for the client screen > Part of the point of removing t.screen and moving it to lua was an attempt at > getting rid of all of those problems... (Although it didn't really work out, > I confess) I understand that, I usually advocate the "all in lua" dogma, but in this case, I don't see how we can fix _all_ the issues if the code is not centralized. Then, it wont ever cover all use case, some people want shifty-like relative indexes too https://github.com/Elv13/tyrannical/issues/10 It also wont really cover the filtered taglist use case... > I can't see the point of a *read-only* index property that is managed in C. Maybe the lua side should be able to keep "persistent" filtered taglist. Maybe it is just a better idea than what this issue propose. Feel free to close it if you agree, if you do, I will write the "persistent filtered tag list" to feed whatever widgets will be in front of it. The bug is real, but I forgot about the filtered tag list use case and a global index wont cover it. Better dropping the whole index thing instead of fixing it. This also apply to awful.tag.byidx and the likes, they also don't cover the filtered list use case, so they should be deprecated and eventually renamed to something else. The users should query that persistent list entity instead of the global one. -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment3889 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Uli Schlachter (psychon) -- The bug report ends in the middle of a sentence. I can't see the point of a *read-only* index property that is managed in C. Are you asking for changes to awful.widget.taglist? Not reload everything all the time? Do you just want some code in lua that "updates" a tag's index when it get deactivated? If you want to reintroduce t.screen, what should happen to clients which are on different screen than their tag? What if a client has three tags which all belong to different screens and only one of them has the same screen than the client? What if a tag has three clients that all have different tags? How would all of this work? Oh and how would we map tags to _NET_WM_DESKTOPS? First all tags of the first screen, then the second screen etc? Part of the point of removing t.screen and moving it to lua was an attempt at getting rid of all of those problems... (Although it didn't really work out, I confess) (Won't comment about the complexity) TL;DR: All I can see clearly is "Tag 'index' is broken", everything more is confusing... -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment3884 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1229 - Tag "index" is not handled properly User who did this - Emmanuel Lepage Vallee (Elv13) -- While looking at awful.tag.gettags() to do a quick fix to my problem. I came to think that the way the tags are stored is the main problem here. First, selecting a tag is O(n) instead of O(1), but then there is this dual concept of index. One is stored in the property, but all function referring to idx use the gettags()[] index. Gettags is also called way too many time, making tags switching exponentially slow relative to _both_ the number of tags _and_ the number of screens. I think a capi.tag object should have a read only index, that the C core should keep a list of tags per screen (and a global one, because we still need it). The screen should also be kept and managed in the C side and clients should have their screen match the tag screen on the C side too. Doing it in the "upper levels" of the API such as awful is the source of about 10 known bugs, including 2 that Tyrannical "monkey patch" at runtime. As you said, what Tyrannical is doing is deeply wrong, but is better than having the bugs. We should have a way to get the index without being O(N^2) (looping to create the index map, then looping to find the tag index). -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229#comment3881 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[awesome bugs] #1229 - Tag "index" is not handled properly
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Emmanuel Lepage Vallee (Elv13)
Attached to Project - awesome
Summary - Tag "index" is not handled properly
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - git/master
Due in Version - Undecided
Due Date - Undecided
Details - In the current awful.widget.taglist implementation, everything is
reloaded when something changes. This in itself solve a lot of issue, but has
some limitations. My Blind library relied on a ton or very dirty hacks to keep
track of states and display the correct content. These days, I use a new
Radical based implementation. It is much easier to extend and even a little
faster because of the lower rate of reloads.
The problem is that capi.tag/awful.tag implementation of tag indexes is
currently broken. See
tag.connect_signal("property::index",function(t,i)
print("A tag index changed",t,awful.tag.getidx(t),t.name)
end)
print("deleting a tag")
awful.tag.delete(awful.tag.gettags(1)[1])
When adding/removing/moving tags, the signal is not called. This, in turn,
cause my implementation to just fail to reflect the current order, so both tags
"number" (aka: "(1) Term") is wrong and the keyboard keys wont select the tag
you expect them to select.
I could solve that by keeping track of the indexes myself, but that would suck.
The current way indexes are managed is just wrong. It is both slow and buggy.
What do you think would be the best way to handle this?
The "cheap way" to fix this is add
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1229
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
