Probably caused by some bug with column etc on the Ubuntu version being used on Travis.

Ref: #11 (comment)

I'm slowly but surely closing hosting services that host the current awesome website. That'd mean moving out the static website, and the Mediawiki instance running.

There's no hard deadline yet, the soft deadline being 31st December 2016.

I noticed that https://travis-ci.org/awesomeWM/awesome-www/builds/217685669 failed and wondered why. The difference seems to be penlight 1.4.1 vs penlight 1.5.0. The issue seems to be tracked at lunarmodules/Penlight#243.
If needed, we could pin penlight 1.4.1 for the time being. However, I hope that upstream will fix this and do an update soonish.

AwesomeWM DevEnv

Basic user configurations, simple wibars, layouts, basic themes don't need libs import and looking to the libraries of AW project. It is possible to use with the AW API and its documentation.

However, this will quickly change if you need to start doing more complex things and components. When using Lua components, it is often necessary to look at implementations and cooperation already written in the AW library.

Furthermore, there may be a large group of people who can begin to contribute to AW fixes and enhancements; so that stable versions have a shorter release cycle again.

I don't think I'll be alone who lacks simple tutorials on how to run a "quality" environment for AW development; source code and AW debugging are available throughout the project, as used by contributors to this project.

Furthermore, I think that this will also help to unify the use of some of the tools that are needed for this.

So is it possible for experienced contributors to create a quality guide for setting up a development environment to contribute to a project and include it on the main AW pages? This can open the door to the points which are already described.

Via awesomeWM/awesomeWM.github.io@dc92eee#commitcomment-20293357:

It turns out that the footer of the image changes:

Via diff -u =(git show c646eb972d:index/382x216-screen.png | hexdump -C) =(git show c646eb972d~1:index/382x216-screen.png | hexdump -C):

--- /tmp/zshyQ69o4	2016-12-25 23:29:12.822000142 +0100
+++ /tmp/zshMuqqOv	2016-12-25 23:29:12.842000400 +0100
@@ -4988,9 +4988,9 @@
 000137b0  12 c6 08 17 94 d1 ff 17  a1 9b 74 be e4 47 27 ce  |..........t..G'.|
 000137c0  00 00 00 25 74 45 58 74  64 61 74 65 3a 63 72 65  |...%tEXtdate:cre|
 000137d0  61 74 65 00 32 30 31 36  2d 31 32 2d 32 35 54 32  |ate.2016-12-25T2|
-000137e0  32 3a 31 30 3a 32 35 2b  30 30 3a 30 30 e7 9f f3  |2:10:25+00:00...|
-000137f0  d5 00 00 00 25 74 45 58  74 64 61 74 65 3a 6d 6f  |....%tEXtdate:mo|
+000137e0  31 3a 34 32 3a 32 36 2b  30 30 3a 30 30 1e 1f f9  |1:42:26+00:00...|
+000137f0  f9 00 00 00 25 74 45 58  74 64 61 74 65 3a 6d 6f  |....%tEXtdate:mo|
 00013800  64 69 66 79 00 32 30 31  36 2d 31 32 2d 32 35 54  |dify.2016-12-25T|
-00013810  32 32 3a 31 30 3a 32 35  2b 30 30 3a 30 30 96 c2  |22:10:25+00:00..|
-00013820  4b 69 00 00 00 00 49 45  4e 44 ae 42 60 82        |Ki....IEND.B`.|
+00013810  32 31 3a 34 32 3a 32 36  2b 30 30 3a 30 30 6f 42  |21:42:26+00:00oB|
+00013820  41 45 00 00 00 00 49 45  4e 44 ae 42 60 82        |AE....IEND.B`.|
 0001382e

Link to wiki(https://awesomewm.org/wiki/) shows me this:

Is this something wrong on my end? Was working fine few days ago.

https://github.com/awesomeWM/awesome-www/settings/secrets/actions

also somebody would need to set:
AWESOME_ROBOT_TOKEN
CLOUDFLARE_ZONE
CLOUDFLARE_AUTH_EMAIL
CLOUDFLARE_AUTH_KEY

Originally posted by @actionless in #170 (comment)

The reference is not linked.
https://github.com/awesomeWM/awesome-www/blob/master/.travis.yml#L77

awesomeWM/awesomeWM.github.io@7bd624f

Followup to #22.

It might help to see what's being looked at.

This would go into https://github.com/awesomeWM/awesome/blob/master/build-utils/travis-apidoc.sh.

Clearly Something is Wrong!

Not only is it somewhat hard to understand the vast majority of the documentation pages because they lack examples that coherently demonstrate the usage of whatever it is you found yourself looking at in an actual context users could find themselves in (which is hard to write in the source code comments the docs are being generated from, but some pages seem to manage, so shouldn't that be added to the contribution requirements of the source code?)...

but someone did not appropriately set up the sidebar's overflow in CSS

Solution? Solution!

I would fix this myself, but I am busy at the moment with my config, a project that's gone on for years now and I would like to finish it, so you will have to wade through the css that is applied to what is pulled out of source code and smashed into the documentation site but I can help you with the specific rule you will need to add to the appropiate selector at least.

What It Will Look Like in Code

.whatever-the-selector-is-called {
// ...other random css
overflow: auto;
// or
overflow: hidden 
}

Current State's Probable CSS

its probably set to visible now, which is fine if you don't mind the bleed over I highlighted in my screenshot but personally I can't stand that.

CSS Selector Replacement Rationale

• auto - adds scrollbars if needed (almost never actually needed, but in case you just have to read the link in the little sidebar space)

• hidden - because its a link, this works since hovering over the link will make its content appear if not in a popup, on the bottom status bar of most browsers. This should be enough for most people

That's It

Either prevents the bleed over that cannot be read by anyone, regardless of preference.

Via #64:

the current URL suffix for the stable branch docs is called doc/api, isn't it better to rename it to something related to that specific stable version (like /api/v4.0) for example.

Yes, we should include the version in the docs we are building, and then have a api symlink to the current one.

This would mean to not overwrite old docs when pushing it to https://github.com/awesomeWM/awesomeWM.github.io probably?

Arch, Debian Sid and Ubuntu zenial all pushed 4.0, breaking everybody's config. We've been there before, but it has been a looong time. We need a temporary message on the homepage (very visible) pointing the users in the right direction:

https://awesomewm.org/apidoc/documentation/89-NEWS.md.html
https://awesomewm.org/apidoc/documentation/17-porting-tips.md.html

Via #37 (comment)

branches.only: master in .travis.yml…
Can we remove that setting and instead use some if with $TRAVIS_BRANCH to make sure only non-PR builds for the master branch update the web page?

Please consider using English version Paypal for the donation information page. It looks like French(?) currently.

The link to the "Aesthetic night" Theme under the Themes section on
https://awesomewm.org/recipes/
is outdated and leads to a 404

I came across https://www.reddit.com/r/awesomewm/comments/mljthp/website_css_improvements/ and wanted to leave a link here.

Feel free to just close this issue.

See http://new.awesomewm.org/, which contains:

[[!img Error: Image::Magick is not installed]]

Via #112 (comment).

I found this answer on SE and the two widgets mentioned there look quite interesting. It might be worth considering putting them in the recipes page.

I can't find the original content.

https://askubuntu.com/questions/359988/how-to-have-a-volume-control-widget-in-awesome-wm

          @Elv13 i think would be nice at some point to get mb some basic luacheck linting for the recipes in the CI

Originally posted by @actionless in #179 (comment)

Right now, the website seems to be down.

Cloudflare offers some backup access, but some pages of the wiki do not work altogether.

We already talk about it in #161, but the topic was about development environment, not directly focused to the website. I thought about it longer time and try to find some good solution for it.

Features

There are some features which can be expected from new website

• New professional theme in dark mode
• Main page with complete overview, descriptions, features, links. And big Get Started button for next actions and new users to continue with AW
• In Top menu: Welcome, Docs, Recipes, Showcase, [Blog], Community, Github
• Template fast driven webpage design
• Markdown for fast edition of pages
• Good administration of website - updates, backup, user access
• Long-term framework and basement for pages

Tasks

• Rewrite actual website to new style.
• Provides basic tutorials, installation guides in markdown; linkage to the awesome framework documentation.

Framework for building websites

There are many choices. I was pleased with several solutions and a certain firm decision was not made.

However, I really like this solution

• Doks Modern Documentation Theme. Look to Showcase tab too!
• Doks is theme, open source project based on the HUGO - framework for building websites.

About Hugo

Hugo is a general-purpose website framework. Technically speaking, Hugo is a static site generator. This means that, unlike systems like WordPress, Ghost and Drupal, which run on your web server expensively building a page every time a visitor requests one, Hugo does the building when you create your content. Since websites are viewed far more often than they are edited, Hugo is optimized for website viewing while providing a great writing experience.

Sites built with Hugo are extremely fast and very secure. Hugo sites can be hosted anywhere, including Heroku, GoDaddy, DreamHost, GitHub Pages, Google Cloud Storage, Amazon S3 and CloudFront, and work well with CDNs. Hugo sites run without dependencies on expensive runtimes like Ruby, Python or PHP and without dependencies on any databases.

We think of Hugo as the ideal website creation tool. With nearly instant build times and the ability to rebuild whenever a change is made, Hugo provides a very fast feedback loop. This is essential when you are designing websites, but also very useful when creating content.

Conclusion

• I don't know who is hosting the current offline pages now. Can server support libs and technology necessary for Doks?
• What are your ideas about this change?
• How can decide if this change can be realized?
• I can start with some first prototypes, demos. It depends on main dev team. Provide some opinions and actions which have to be make.

The site currently has 2 doc tabs (v4.0 and git/master), but this information is already contained one tab (v4.0). Wouldn't be wiser to keep one single doc tab with all documentation information.

Also, the current URL suffix for the stable branch docs is called doc/api, isn't it better to rename it to something related to that specific stable version (like /api/v4.0) for example.

Go to http://new.awesomewm.org/download/, click on a download link and see a 404 at http://new.awesomewm.org/download/awesome-3.5.9.tar.bz2 .

(TODO: Check for other 404s on the new web page and handle them all)

The certificate has been expired on March 7th. Please update.

Hi!
While rewriting my rc.lua to awesome4(thank you for the nice work btw ;-) ) i noticed some 'over-escaped' statements in the examples section of https://awesomewm.org/apidoc/classes/wibox.widget.progressbar.html# that shouldn't be there
example:

value         = <span class="number">0.33</span> 

should be:

value         = 0.33

When clicking links such as:
https://awesomewm.org//changelogs/v4.0

the content type is unset, so the browser downloads it. It should be renamed with an extension such as .txt or the server should send the proper Content-Type header.

https://validator.w3.org/check?uri=http%3A%2F%2Fawesomewm.org&charset=%28detect+automatically%29&doctype=Inline&group=0

https://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fawesomewm.org&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en

(but not only the main page should be checked, but also sub pages)

I just saw the mailing list has been closed so please advise if this is not the right place to ask this question.

I notice the latest Awesome version places title bars on windows of type "dialog", however I am getting title bars on my Promoe (XMMS2 media player) windows that shouldn't be there.

There are two Promoe windows, one with a title bar and one without (both should not have title bars.)

The correct window, that has no title bar, has xprop say this:

_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE,
  _NET_WM_WINDOW_TYPE_NORMAL

However the incorrect window, that has a title bar and should not have one, says this:

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG,
  _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL

It looks like the rule in the default config that puts title bars on dialog boxes needs to be changed so that it puts title bars on dialog boxes except if they have _NET_WM_WINDOW_TYPE_OVERRIDE also.

I am not sure how to update this rule however so any advice would be appreciated!

Hello,
while integrating MPD into my rice i stumbled over a bug in the sample widget on the awesome website. The sample widget uses this error handler:

local function error_handler(err)
    mpd_widget:set_text("Error: " .. tostring(err))
    -- Try a reconnect soon-ish
    timer.start_new(10, function()
        connection:send("ping")
    end)
end

When mpc:_connect fails and try_reconnect is false this method gets called two times and thus two timers are created. Each timer then again calls mpc:_connect. When no connection can be made, after some time this completely stops awesome from working.

As the server is going away, it's unlikely the mailing list hosted [email protected] still stay longer too. I can provide the list of subscriber and even a mail alias, but it should probably go be hosted elsewhere. I've no idea where we can find such a service, but it should be possible. (Freedesktop.org maybe?)

Deadline is 31st December 2016.