Re: [PATCH + RFC] awful.doc reactivation

2009-09-03 Thread Julien Danjou
At 1251908089 time_t, koniu wrote:
 Actually, looking at the extent of naughty dependency (and therefore a
 necessity to do a lot of different callbacks) I'm leaning towards your
 first suggestion which is splitting it out of awful and calling it
 'handy' instead (unless someone has a better name - ideas welcome).

Seems fair, at least for now.

-- 
Julien Danjou
// ᐰ jul...@danjou.info   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// This is the end of my signature.


signature.asc
Description: Digital signature


Re: [PATCH + RFC] awful.doc reactivation

2009-09-02 Thread Julien Danjou
At 1251821489 time_t, koniu wrote:
 Alternative solution is to catch these duplicates in
 awful.help.format.kb_list(), perhaps under condition that the
 modifiers might be different but keysym is the same + the
 doc.description is the same. This would add yet another loop to
 format.kb_list() which is already pretty loaded, which is why I chose
 this shortcut. I could try hack up duplicate detection tho.

Would be cleaner IMHO.

 My initial plan was to clearly split help generation into frontend
 and backend where everything is returned in some standard manner and
 then you can display it in naughty or just get a string or whatever.
 Eventually my awful.help functions ended up in having a load of pango
 markup so I just left naughty as a dependency. Having used it for more
 than 3 months now I have to say that I've experienced no ill-effects
 to that.

Well I am sure there's no ill effect, it's just a cyclic-dependency we
should try to avoid.

 What's your view?

Well, my view is rather more complicated than it should be,
and not only related to awful.doc.

The thing is that naughty is handling 2 things currently: wibox
creation, placement, etc and notification system (Lua + D-Bus).

What we're needing more and more inside awesome is not notification
itself, but wibox creation/placement handling. You need it for your
keybinding stuff in awful.doc. and for example, I'd need it if I wanted
to add a wibox with a mini-calendar when clicking on the awful.widget.textclock
there's on my wibox-statusbar.

So ultimately, naughty should be somehow splitted to handle notification
and use wibox creation/system from awful.

Ok, I know this is not gonna be solve the problem of awful.doc *right
now*, but that's currently how I see things.

Now, to solve *that* problem, there's 2 solution:
- move awful.doc outside awful, so it can depends on awful + naughty,
  which would on the same level as it;
- just implement a callback system where you give a function to
  awful.doc that will be called with text to be printed as argument.

 This is something I'm gonna be looking into. Also luadoc is pretty
 flexible and you can have any fields you want so perhaps we could look
 into closer integration.

Great idea. Keep me in touch. :)

Cheers,
-- 
Julien Danjou
// ᐰ jul...@danjou.info   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Anna Molly! Anna Molly! Anna Molly!


signature.asc
Description: Digital signature


Re: [PATCH + RFC] awful.doc reactivation

2009-09-02 Thread Julien Danjou
At 1251904856 time_t, koniu wrote:
 There's incremental commits that will eventually be squashed.

Please do so if you think it reduce the review size. ;)

 On Wed, Sep 2, 2009 at 09:33, Julien Danjoujul...@danjou.info wrote:
  At 1251821489 time_t, koniu wrote:
 
  this shortcut. I could try hack up duplicate detection tho.
  Would be cleaner IMHO.
 
 Done. I think that perhaps the new function awful.help.compare_kb()
 could replace awful.key.match() altho then I'd have to add analogous
 function to awful.button. Gonna look into it.

As you please. ;)

  My initial plan was to clearly split help generation into frontend
  and backend
 
  - just implement a callback system where you give a function to
   awful.doc that will be called with text to be printed as argument.
 
 That's what I was thinking. Question is, where ought the default
 callback function(s) be defined.

rc.lua ?

 Another small issue - awful.help.get(widget) doesn't get descriptions
 for 'buttons' and 'extents': http://omploader.org/vMjlvYg.

That's a more general/logic problem: there are object methods, and we
only set object methods available on object.

We should probably export object methods to their module also:
mywidget:buttons() and mywidget.buttons(mywidget) already
and then we should have
widget.buttons(mywidget) working also.
I can't see why we should not do that.
i.e. it's like Lua string module.

That's something I can add as soon as I've time, if no one goes into it
before me.

Cheers,
-- 
Julien Danjou
// ᐰ jul...@danjou.info   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// My root password is


signature.asc
Description: Digital signature


Re: [PATCH + RFC] awful.doc reactivation

2009-09-02 Thread koniu
Another little update on a previously discussed matter:

16:37  koniu lol i tried retrieving keybinding descriptions for the
cheat-sheet from descriptions of functions they're bound to and it's
unimpressive :) http://omploader.org/vMjlwNg
16:40  koniu too many inline functions in the default rc
16:42  koniu i think i'm gonna stick with documenting everything as
it is, at least it gives pretty verbose explanation to anyone who's
looking at the default config

Having said that, I will keep the attempt to retrieve descriptions
from functions in awful.key but these will be overridden by any
definitions made in awful.key.new(). At least people who haven't
migrated their configs to include descriptions will have _something_
there.

k

-- 
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.


Re: [PATCH + RFC] awful.doc reactivation

2009-09-02 Thread Julien Danjou
At 1251906585 time_t, koniu wrote:
 Having said that, I will keep the attempt to retrieve descriptions
 from functions in awful.key but these will be overridden by any
 definitions made in awful.key.new(). At least people who haven't
 migrated their configs to include descriptions will have _something_
 there.

+1.

-- 
Julien Danjou
// ᐰ jul...@danjou.info   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// The more we fly, the more we climb, the more we know that heaven is a lie.


signature.asc
Description: Digital signature


Re: [PATCH + RFC] awful.doc reactivation

2009-09-02 Thread koniu
On Wed, Sep 2, 2009 at 16:39, Julien Danjoujul...@danjou.info wrote:
 At 1251904856 time_t, koniu wrote:
 There's incremental commits that will eventually be squashed.
 Please do so if you think it reduce the review size. ;)

I'll keep the increments for now, since it's easier for me to track
progress and squash them when we'll be getting closer to finalizing
the review.

  - just implement a callback system where you give a function to
   awful.doc that will be called with text to be printed as argument.

 That's what I was thinking. Question is, where ought the default
 callback function(s) be defined.

Actually, looking at the extent of naughty dependency (and therefore a
necessity to do a lot of different callbacks) I'm leaning towards your
first suggestion which is splitting it out of awful and calling it
'handy' instead (unless someone has a better name - ideas welcome).


 Another small issue - awful.help.get(widget) doesn't get descriptions
 for 'buttons' and 'extents': http://omploader.org/vMjlvYg.

 We should probably export object methods to their module also:
 mywidget:buttons() and mywidget.buttons(mywidget) already
 That's something I can add as soon as I've time, if no one goes into it
 before me.

That would be great. I'll leave this to you (or whomever wants to
boost their commit rank, hint hint psychon :p).

kk

--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.


Re: [PATCH + RFC] awful.doc reactivation

2009-09-01 Thread koniu
On Tue, Sep 1, 2009 at 13:05, Julien Danjoujul...@danjou.info wrote:
 I've a couple of things to add:
 - awful.{button,key}: you set description only on ret[1], which seems
  not right, all returned objects should have a description set.

Ha, yes, I don't like this either - it's a hack.

It allows avoiding duplicates in the keybinding cheat-sheet. The
function retrieves root.keys() and client.focus.keys() and displays
those. There we don't care about Caps + Mod4 + x being lua prompt
along Mod4 + x.

Alternative solution is to catch these duplicates in
awful.help.format.kb_list(), perhaps under condition that the
modifiers might be different but keysym is the same + the
doc.description is the same. This would add yet another loop to
format.kb_list() which is already pretty loaded, which is why I chose
this shortcut. I could try hack up duplicate detection tho.

 - awful.help require naughty. That's not a bad thing IMHO, but that
  raises again the awful-naughty dependency. We should discuss that.

My initial plan was to clearly split help generation into frontend
and backend where everything is returned in some standard manner and
then you can display it in naughty or just get a string or whatever.
Eventually my awful.help functions ended up in having a load of pango
markup so I just left naughty as a dependency. Having used it for more
than 3 months now I have to say that I've experienced no ill-effects
to that.

What's your view?

 - I did not tried you branch (I can't right now), but I'm not sure if
  you amended correctly my patch generating documentation. The C API
  documentation is no more auto-generated. Be careful.

As mentioned on irc, I'm working on that atm.

 thought of would be automagic description retrieval for
 buttons/keybindings based on the functions that they execute. So
 instead of having to do

 I'm not sure (i.e. I can't recall) but I wonder if there's not 2 part in
 a function documentation in luadoc (a summary and a complete
 description). I unfortunately cannot check right now, but you can take a
 look by hacking lua-doc-generate.lua to see what type of documentation
 is available from luadoc data structure.

This is something I'm gonna be looking into. Also luadoc is pretty
flexible and you can have any fields you want so perhaps we could look
into closer integration.

 Btw, you should send me (patch or pull request) the patch totally unrelated
 to awful.doc, I'll review and merge. That should split the workload of
 rebasing/reviewing. :)

Done and merged - thanks.

cheers,
k

--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.


[PATCH + RFC] awful.doc reactivation

2009-08-31 Thread koniu
Heyup. I finally got around to clean up my awful-doc branch a bit.

Starting a new thread not to cause too much confusion. Original one is here:
http://www.mail-archive.com/awesome-devel@naquadah.org/msg02191.html

Current version of the branch is available here:
http://git.mercenariesguild.net/?p=awesome.git;a=shortlog;h=refs/heads/awful-doc

There's a couple of patches for awful.prompt but only the 'font' one
is related. Other ones are general improvments/fixes.

There's not much news in terms of functionality (it's been fairly
complete for months now) and now after a bunch of rebases with plenty
of edits and squashes the branch and code proposed should be cleanish,
maybe lacking a bit of comments which I will be happy to provide in
the near future.

I'm most interested in feedback regarding adding actual descriptions
to the default rc.lua and awful submodules, and their content. As you
can see I've added a bunch of descriptions inside awful.widget.* and
I'm wondering if taglist/tasklist should be handled the same way or
whether it should be as it is now - inside rc.lua.

Perhaps this could be a post-merge target, but one nice thing I
thought of would be automagic description retrieval for
buttons/keybindings based on the functions that they execute. So
instead of having to do

   awful.button({ }, 4, awful.tag.viewnext, nil, Switch to next tag)

to set the description in rc.lua, the function trying to display docs
for that button would check description for awful.tag.viewnext. That
would make transition from non-described rc.lua to having a keybinding
cheatsheet much easier. There are a few problems with it however:

- descriptions taken from luadoc are a bit dirty (eg
awful.tag.viewnext it's View next tag. This is the same as
tag.viewidx(1) which obviously is a bit too long for a summary of
bindings. so luadoc for everything would need to be cleaned up a bit
which seems like a big task.
- grouping of bindings (try mod+f1 and k to see what i mean) is done
in rc.lua by setting a default group before each section of binding
definitions, eg:
awful.doc.set_default({ group = Navigation }),
awful.key({ modkey,   }, Left,   awful.tag.viewprev
 , nil, View previous tag),
awful.key({ modkey,   }, Right,  awful.tag.viewnext
 , nil, View next tag),
...
so if we do that keybinding grouping would have be done in a slightly
different way, not sure how.
- there's a bunch of inline functions in rc.lua already so inline
descriptions for those are unavoidable.


Phew.

lets get it going.
k

-- 
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.