[awesome bugs] #368 - Wide icons cause overlapping items in the tasklist (gimp)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#368 - Wide icons cause overlapping items in the tasklist (gimp) User who did this - Julien Danjou (jd) -- This is fixed, but not the way I want. I'm tagging this for 3.2, because that may require some deeper changes in imagebox code. -- More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=368#comment882 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 [EMAIL PROTECTED]
Re: make error in 3.1rc
Thanks, that was it. :) Vinno. [EMAIL PROTECTED] On Mon, 10 Nov 2008, Julien Danjou wrote: At 1226310657 time_t, Vinno wrote: /usr/local/share/awesome/lib/awful.lua:1586: attempt to index field This is an old file which is no more used in 3.1. Remove it. Cheers, -- Julien Danjou // ᐰ [EMAIL PROTECTED] http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
Re: make error in 3.1rc
Okay, I ignored it and continued with make install. After a restart I get .xsession-errors: and awesome isnt running in px -aux. The awesome --check says config is okay, even used the default git one just incase. Well anyways, heres the errorsession. /etc/gdm/Xsession: Beginning session setup... Setting IM through im-switch for locale=en_AU. Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default. /usr/local/share/awesome/lib/awful.lua:1586: attempt to index field 'titleupdate' (a nil value) Vinno. [EMAIL PROTECTED] On Mon, 10 Nov 2008, Julien Danjou wrote: At 1226297923 time_t, Vinno wrote: Using Ubuntu with awesome 3.0 fine but when I try the git rc3.1 I get errors on make. Any idea guys? This are not errors but warning. Seems that asprintf is declared with warn_unused_result on your side, which seems weird but why not. I'll try to fix that. Cheers, -- Julien Danjou // ᐰ [EMAIL PROTECTED] http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
[awesome bugs] #370 - strange clients order in tile layout (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#370 - strange clients order in tile layout User who did this - Tanguy Ortolo (Elessar) -- The bug tracking system broke my ASCII drawings, so here they are again, but in an attached file. -- One or more files have been attached. More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=370#comment883 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 [EMAIL PROTECTED]
[awesome bugs] #370 - strange clients order in tile layout
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Tanguy Ortolo (Elessar) Attached to Project - awesome Summary - strange clients order in tile layout Task Type - Bug Report Category - Layouts Status - Unconfirmed Assigned To - Operating System - Linux Severity - Low Priority - Normal Reported Version - 3.0 Due in Version - Undecided Due Date - Undecided Details - When using the tile layout, with one master and two scondary columns, one master client and three secondary ones, here is how they get ordered: +---+---+---+ | 1 | 2 | 4 | | | +---+ | | | 3 | +---+---+---+ The strange thing is that the third client comes under the fourth one, contrary to what one would expect. With one master client and 5 secondary ones: +---+---+---+ | 1 | 2 | 5 | | | +---+ | +---+ 6 | | | 3 +---+ | | | 4 | +---+---+---+ Here, the order in the last column is definitely not what a sane person would expect, and it is rather disturbing when switching the focus or moving a client with the keyboard short cuts: [On client 6] Okay, next client… Hey, what do I do on the master client?” More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=370 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 [EMAIL PROTECTED]
[awesome bugs] #371 - unescaped ampersand in tasklist textbox cause error (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Robert Kling (mccord)
Attached to Project - awesome
Summary - unescaped ampersand in tasklist textbox cause error
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - git/master
Due in Version - Undecided
Due Date - Undecided
Details - hello
whenever my tasklist (for example a website title) or my conky textbox (mpd artist or title) contains an ampersand ('')
awesome throws the following error:
markup_parse:175: unable to parse text conky_output_or_window_title_here
Error on line 1: Character ' ' is not valid at the start of an entity name:
the character begins an entity; if this ampersand isn't supposed to be an entity,
escape it as amp
and the textboxes stay empty.
this does not happen with the tasklist from the default config
i use the following tasklist code:
tasklist[s] = awful.widget.tasklist.new(function(c)
if c == client.focus then
return spacer..c.name..spacer
end
end, tasklist.buttons)
i guess c.name contains the unescaped ampersand
and my conky textbox:
conkywidget = widget({ type = textbox, name = conkywidget, align = right
})
i'm using awesome-git version v3.1-rc1-22-gc13654f
i'll attach both my full rc.lua and .conkyrc, let me know if you need any more
infos!
One or more files have been attached.
More information can be found at the following URL:
http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=371
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 [EMAIL PROTECTED]
[awesome bugs] #371 - unescaped ampersand in tasklist textbox cause error
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#371 - unescaped ampersand in tasklist textbox cause error User who did this - Julien Danjou (jd) Reason for closing: Not a bug Additional comments about closing: You need to escape your text (awful.util.escape()) More information can be found at the following URL: http://awesome.naquadah.org/bugs/index.php?do=detailstask_id=371 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 [EMAIL PROTECTED]
Re: [PATCH] improve tag switching performance (unmap vs. move)
On Mon, Nov 10, 2008 at 08:22:38PM +0100, Julien Danjou wrote: At 1226343520 time_t, Erik Garrison wrote: Specifically, what aspects of composite do you think would be nice to have in Awesome, and what can we do to get them enabled? TBH I don't care about composite and I won't modify any line of awesome code to enable such a thing, unless it make awesome more standard compliant or at least does not change that. It's even probable that your code does not break (m)any apps, but well, awesome cannot allow itself to diverge from standard for external applications reasons, even for eye candies. If standards are not good, and I don't judge them here, please change them rather than hack awesome. I think that we can perhaps resolve the issue by turning back to the standards, in this case the EWMH: (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505544) [Virtual desktops] Implementation note There are at least two options for implementing virtual desktops. The first is to use multiple virtual roots (see the section called “Implementation note”) and change the current desktop by manipulating the stacking order of the virtual roots. This is completely ICCCM compliant, but has the issues outlined in the section called “Implementation note” The second option is to keep all managed windows as children of the root window and unmap the frames of those which are not on the current desktop. Unmapped windows should be placed in IconicState, according to the ICCCM. Windows which are actually iconified or minimized should have the _NET_WM_STATE_HIDDEN property set, to communicate to pagers that the window should not be represented as onscreen. As the standard notes, we could, instead of iconifying our windows, place them in virtual root windows and change the stacking order of the virtual roots to switch tags. This would be wholly standards compliant and would prevent the unnecessary unmapping and remapping of windows. Have you evaluated this solution? Erik -- To unsubscribe, send mail to [EMAIL PROTECTED]
Re: [PATCH] improve tag switching performance (unmap vs. move)
On Mon, Nov 10, 2008 at 11:25:27PM +0100, Maarten Maathuis wrote: On Mon, Nov 10, 2008 at 8:22 PM, Julien Danjou [EMAIL PROTECTED] wrote: At 1226343520 time_t, Erik Garrison wrote: Specifically, what aspects of composite do you think would be nice to have in Awesome, and what can we do to get them enabled? TBH I don't care about composite and I won't modify any line of awesome code to enable such a thing, unless it make awesome more standard compliant or at least does not change that. It's even probable that your code does not break (m)any apps, but well, awesome cannot allow itself to diverge from standard for external applications reasons, even for eye candies. If standards are not good, and I don't judge them here, please change them rather than hack awesome. Seems that composite/xcompmgr is broken by design or need hack on _its_ side, not on awesome's one. Cheers, -- Julien Danjou Strictly speaking i do not know how this is a violation of ICCCM, because the client did not request to be unmapped. I'd be curious what precisely the violation is (a quote would be helpful). There are two components. ICCCM: http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.5 4.2.5. Iconify and Deiconify A top-level window that is not Withdrawn will be in the Normal state if it is mapped and in the Iconic state if it is unmapped. This will be true even if the window has been reparented; the window manager will unmap the window as well as its parent when switching to the Iconic state. The client can elect to be notified of these state changes by selecting for StructureNotify events on the top-level window. It will receive a UnmapNotify event when it goes Iconic and a MapNotify event when it goes Normal. and EWMH: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505544 Virtual Desktops Most X servers have only a single screen. The window manager may virtualize this resource and offer multiple so-called 'virtual desktops', of which only one can be shown on the screen at a time. There is some variation among the features of virtual desktop implementations. There may be a fixed number of desktops, or new ones may be created dynamically. The size of the desktops may be fixed or variable. If the desktops are larger than the root window, their viewports (see the section called “Large Desktops”) may be independent or forced to be at the same position. A window manager which implements virtual desktops generally offers a way for the user to move clients between desktops. Clients may be allowed to occupy more than one desktop simultaneously. Implementation note There are at least two options for implementing virtual desktops. The first is to use multiple virtual roots (see the section called “Implementation note”) and change the current desktop by manipulating the stacking order of the virtual roots. This is completely ICCCM compliant, but has the issues outlined in the section called “Implementation note” The second option is to keep all managed windows as children of the root window and unmap the frames of those which are not on the current desktop. Unmapped windows should be placed in IconicState, according to the ICCCM. Windows which are actually iconified or minimized should have the _NET_WM_STATE_HIDDEN property set, to communicate to pagers that the window should not be represented as onscreen. We need to pick one of the two implementation patterns described above to be standards compliant. Erik -- To unsubscribe, send mail to [EMAIL PROTECTED]
