Roguelike project?
Tim Mcd
Email me/post here!
(tmcd...@gmail.com)
--
Posted via http://www.ruby-forum.com/.
Matthew Moss
> Email me/post here!
Interested in playing? Testing? Developing?
I've considered writing one at some point, but I've yet to make time
and figure out ncurses.
Tim Mcd
Sorry: That would be interested in developing. I am novice-intermediate
when it comes to Ruby code, but I thought it would be fun to create a
Ruby roguelike.
Nit Khair
It would be fun, certainly. Recently, i wrote my first ncurses program,
a snakes game and it was great fun. Since then, I am working on a much
larger ncurses project - would have loved to work with you.
ncurses is pretty easy and fun - one problem i occasionally face is
getting the refreshes correct - otherwise its cool. Remember to wrap
your windows in panels, and its better not to use stdscr if you intend
having multiple pages/windows/levels - use panels.
Tim Mcd
Yeah, it's tough finding proper ruby documentation on Ncurses. I've just
been using the Ncurses book linked at the ruby-ncurses site. That is
written for C coding tho, so it's a bit hard porting it over. Panels?
Enlighten me please!
Nit Khair
gives.
2. The only documentation on ncurses is a large file with sample C
program by one
Pradeep Padala which comes up on searching google. It is pretty
comprehensive but mainly examples - no real-world stuff.
3. Usually, I just grep thru the source, esp form_wrap.c and ncurses.rb.
4. Another useful source is "man" (if you are using *nix). This can give
you
explanations of methods. I use it quite a bit.
Forgive my cut-pasting from "man panel" - will explain after:
----
Panels are curses(3X) windows with the added feature of depth.
Panel functions allow the use of stacked windows and ensure the
proper portions of each window and the curses stdscr window are hidden
or displayed when panels are added, moved, modified or removed. The set
of currently visible panels is the stack of panels. The stdscr
window is beneath all panels, and is not considered part of the stack.
A window is associated with every panel. The panel routines
enable you to create, move, hide, and show panels, as well as position
a panel at any desired location in the stack.
Panel routines are a functional layer added to curses(3X),
make only high-level curses calls, and work anywhere terminfo curses
does.
----
Basically, in my app i have a main menu, which calls various programs
and when you return from any program, you come back to the main menu -
its precisely like "alpine". So when Menu calls Contracts, and you
return from Contracts, you want your Menu screen like it was, not with
stuff from Contracts all over. This is best done using panels. A window
gives you a panel. When you remove the panel whats below is
automatically there without your repainting etc.
Pretty neat and efficient compared to many apps I have seen recently
that used windows or stdscr and had to do all this jugglery themselves.
Here's some snips of code to make it clear:
my_form_win = WINDOW.new(rows_to_show,0,startrow ,0)
my_panel = my_form_win.new_panel
Ncurses::Panel.update_panels
In line 2, I create a panel from my window. Pls note that these will go
into instance variables so the caller can destroy them later - V IMP.
Finally, I have a method "free_all" which frees the fields etc. It also
has:
Ncurses::Panel.del_panel(@panel) if !@panel.nil?
@window.delwin if !@window.nil?
The rest of the time, you actually can forget you created a panel, and
just keep writing on the window.
====
Now in your game, i can guess when you jump levels you really don't want
the user to come back (like a stack). However, you could be popping up a
help screen, or a screen where the user can select weapons ... and then
come back to the main screen. So its best to wrap those windows in
panels as shown above. The freeing can be put/called in an ensure block.
Also, you may have some side or bottom panels showing scores, weapons,
time, lives etc. These are best implemented by putting a panel at the
bottom or side.
The snakes game i made was based on the sample code from the Pickaxe and
used only stdscr -- quite ugly if you ask me and it was only one screen
anyway. However, some folks have actually managed to build an entire app
using stdscr only ("sup", iirc). "raggle" otoh uses windows but not
panels, so he has to implement some kind of global array of windows, so
he can pop and push. I don't know their experience in implementing it -
was it clean or did they lose a lot of hair. i can tell you panels
*are* a clean way to implement layered windows.
Michael Fellinger
esp:
http://github.com/manveru/ver/tree/master/lib/ver/keyboard.rb
http://github.com/manveru/ver/tree/master/lib/ver/window.rb
http://github.com/manveru/ver/tree/master/lib/ver/ncurses.rb
I wrote a rougelike in ruby+ncurses, but the source isn't online
anymore, i can send you if you like :)
^ manveru
Nit Khair
>
> http://github.com/manveru/ver
>
> esp:
> http://github.com/manveru/ver/tree/master/lib/ver/keyboard.rb
> http://github.com/manveru/ver/tree/master/lib/ver/window.rb
> http://github.com/manveru/ver/tree/master/lib/ver/ncurses.rb
>
> I wrote a rougelike in ruby+ncurses, but the source isn't online
> anymore, i can send you if you like :)
>
> ^ manveru
Thanks manveru - could you tell me what keyboard.rb does in a nutshell.
I simply bind keys using the "?\C-a" kind of notation to symbols or
procs.
I read your comment in window.rb of the bug that doesnt let you subclass
window. I had a long discussion on this here, i was trying to subclass
Form, iirc. Finally, someone said that the constructor was "shadowed",
so one cannot make another one (I cannot recall the exact words), or
maybe it was private. So i too had wrapped and delegated like you have.
Michael Fellinger
> Michael Fellinger wrote:
>
>>
>> http://github.com/manveru/ver
>>
>> esp:
>> http://github.com/manveru/ver/tree/master/lib/ver/keyboard.rb
>> http://github.com/manveru/ver/tree/master/lib/ver/window.rb
>> http://github.com/manveru/ver/tree/master/lib/ver/ncurses.rb
>>
>> I wrote a rougelike in ruby+ncurses, but the source isn't online
>> anymore, i can send you if you like :)
>>
>> ^ manveru
>
> Thanks manveru - could you tell me what keyboard.rb does in a nutshell.
> I simply bind keys using the "?\C-a" kind of notation to symbols or
> procs.
It allows me to make any object the receiver of keystrokes, simply by doing
Keyboard.focus = something
the object has to respond to the #key method and take the name of the
key (as string) as argument.
So, in my code, once i show or hide a window/pane/view that is
interactive, i simply let it take over the focus of Keyboard and don't
have separate dispatching or some kind of main loop.
keybindings are handled by
http://github.com/manveru/ver/tree/master/lib/ver/keymap.rb
but that's a lot more complicated, building a tree structure and
descends down into it until a matching keybinding is found. that
allows emacs-like keybindings like [C-x C-c].
> I read your comment in window.rb of the bug that doesnt let you subclass
> window. I had a long discussion on this here, i was trying to subclass
> Form, iirc. Finally, someone said that the constructor was "shadowed",
> so one cannot make another one (I cannot recall the exact words), or
> maybe it was private. So i too had wrapped and delegated like you have.
Yeah, it was quite a pain... ncurses.rb already does method_missing,
and then this wrapping introduces another layer, not very nice at all.
Nit Khair
> http://github.com/manveru/ver/tree/master/lib/ver/keymap.rb
> but that's a lot more complicated, building a tree structure and
> descends down into it until a matching keybinding is found. that
> allows emacs-like keybindings like [C-x C-c].
>
through the code a bit
Michal Suchanek
> Anyone interested in a Roguelike game written in Ruby/Ncurses project?
> Email me/post here!
>
> (tmcd...@gmail.com)
>
multibyte characters. So your internationalization possibilities are
limited, and so are things like PC names.
In ruby 1.9 you could possibly set LC_CTYPE and use ncursesw but you
would still have to hack the extension.
I have posted a patch for 1.8 some time ago but that would likely
break stuff in Time or the like because ruby 1.8 does not play well
with setting locale.
Thanks
Michal
Nit Khair
> On 30/10/2008, Tim Mcd <tmcd...@gmail.com> wrote:
>>
> There's one downside to ncurses in Ruby - they do not support
> multibyte characters. So your internationalization possibilities are
> limited, and so are things like PC names.
>
>
>
> Thanks
>
> Michal
Has anyone here used or played about with "slang" / s-lang. Would that
be better in this respect? I don't believe anyone has written a ruby
binding.
What is the work involved to get ncurses-ruby MB enabled ? Is the
problem at the ruby end, or the ncurses end or the binding ?
Michal Suchanek
It's at the Ruby end. 1.8 does not work with locale but ncurses seems
to use locale to determine encoding. Also ruby does not use ncursesw
when they are available.
1.9 could work but the extension would probably have to be updated to
at least link against ncursesw - at least that is how it worked for
me.
Thanks
Michal
Michael Fellinger
Could we use the new Ruby FFI to spare us the C mess?
Nit Khair
> On Sun, Nov 2, 2008 at 7:55 AM, Michal Suchanek <hram...@centrum.cz>
> wrote:
>>>
>> at least link against ncursesw - at least that is how it worked for
>> me.
>
> Could we use the new Ruby FFI to spare us the C mess?
how to link to .so or .a files. The example of getpid seems a little
"magical" to me (*still* a newbie)
Not to go offtopic, but does it mean we can load ncurse.so and then fire
away.
Sean O'Halpin
Yes - the FFI interface is really easy to use. You just need to
specify which lib you are referencing with the #ffi_lib method.
require 'rubygems'
require 'ffi'
module NCursesFFI
extend FFI::Library
ffi_lib 'ncurses'
attach_function 'clear', [], :int
attach_function 'endwin', [], :int
attach_function 'getch', [], :int
attach_function 'initscr', [], :int
attach_function 'printw', [ :string ], :int
attach_function 'refresh', [], :int
end
NCursesFFI.initscr
NCursesFFI.printw("Hello again")
NCursesFFI.refresh
NCursesFFI.getch
NCursesFFI.endwin
Regards,
Sean
Nit Khair
>
> Yes - the FFI interface is really easy to use. You just need to
> specify which lib you are referencing with the #ffi_lib method.
>
> require 'rubygems'
> require 'ffi'
>
> module NCursesFFI
> extend FFI::Library
Seem to be other dependencies other than the gem (which installed fine).
Does it expect Jruby or rubinius ? I get:
>NameError: uninitialized constant FFI::Platform::ARCH_
Or maybe it does not work on OS X yet.
Nit Khair
>
>>NameError: uninitialized constant FFI::Platform::ARCH_
>
> Or maybe it does not work on OS X yet.
It supports "darwin", but not the "powerpc" cpu.
Sean O'Halpin
I'm running on Ubuntu 8.10:
$ ruby -v
ruby 1.8.6 (2007-09-23 patchlevel 110) [i686-linux]
Regards,
Sean
Nit Khair
>> Thanks manveru - could you tell me what keyboard.rb does in a nutshell.
>> I simply bind keys using the "?\C-a" kind of notation to symbols or
>> procs.
>
> It allows me to make any object the receiver of keystrokes, simply by
> doing
> Keyboard.focus = something
> the object has to respond to the #key method and take the name of the
> key (as string) as argument.
> So, in my code, once i show or hide a window/pane/view that is
> interactive, i simply let it take over the focus of Keyboard and don't
> have separate dispatching or some kind of main loop.
manver, i've been pouring through your code, and even tried out ver!
Then for kicks, i linked only keyboard.rb to a sample program and with
only a couple lines added it worked. Prints out the control keys and ESC
key combos.
It even gets Esc-a and Esc-A separately - wonderful. (it did hang when
ESC was pressed twice).
However, it does not accept/print the Alt-keys - is that deliberate, or
did have you not looked into it.
I have had problems with alt-keys (since they generate 2 bytes and that
goes thru my getch() loop twice, often leaving an extra char in the edit
field.
Nit Khair
> Then for kicks, i linked only keyboard.rb to a sample program and with
> only a couple lines added it worked. Prints out the control keys and ESC
> key combos.
> It even gets Esc-a and Esc-A separately - wonderful. (it did hang when
> ESC was pressed twice).
>
Sorry, the hang was due to not setting half-delay. Still want to hear
from you about alt keys.
Michael Fellinger
They seem to work for me just fine, what terminal are you using?
You could look which key codes are pushed into the @stack.
Charles Oliver Nutter
> Nit Khair wrote:
>
>>> NameError: uninitialized constant FFI::Platform::ARCH_
>> Or maybe it does not work on OS X yet.
>
> It supports "darwin", but not the "powerpc" cpu.
Probably just some missing build flags; libffi, on which it's based,
does support Darwin on PPC.
Jump on Ruby-FFI lists if you think you can help debug and get it working:
http://kenai.com/projects/ruby-ffi
- Charlie
Nit Khair
I am using "screen". Its the only one which supported the F1.. keys. My
default xterm-color does not.
> You could look which key codes are pushed into the @stack.
okay, will try that.
Nit Khair
The problem comes here (line 28 of platform.rb).
ARCH = case CPU.downcase
when /i?86|x86|i86pc/
"i386"
when /amd64|x86_64/
"x86_64"
else
28. raise FFI::PlatformError, "Unknown cpu architecture: #{ARCH_}"
end
When i checked my rbconfig.rb I have "powerpc" as the "host_cpu".
So, I changed platform.rb to :
- when /i?86|x86|i86pc/
+ when /i?86|x86|i86pc|powerpc/
.. and now your sample works fine! Thanks.
Forgive me for being spoilt, but is there some script that takes a
header file, or C source and generates the attach_function lines ?
Nit Khair
Still want to hear
>> from you about alt keys.
>
> They seem to work for me just fine, what terminal are you using?
> You could look which key codes are pushed into the @stack.
1. manver. what do the alt-keys print for you (or send to press() ) ?
2. I have found the issue:
when you generate PRINTABLE_KEYS as follows:
PRINTABLE.each do |key|
code = key.unpack('c')[0] # using unpack to be compatible with 1.9
PRINTABLE_KEYS[code] = key
MOD_KEYS[[ESC, code]] = "M-#{key}" unless key == '[' # don't map
esc
end
in line: PRINTABLE_KEYS[code] = key
for ALT-A which is 165, 165.chr = "\245" (slash 245)
the key unpack line generates "-91".
So PRINTABLE_KEYS has: -91 => "\245"
instead of : 165 => "\245"
Thus, nothing is being picked up in line 41:
> NCURSES_KEYS[char] || CONTROL_KEYS[char] || PRINTABLE_KEYS[char]
If I do: "\245"[0], I get 165. btw, I am using ruby 1.8.7 not 1.9.
I did a quick check with:
> key.unpack('C')[0]
and this gives me 165. So perhaps, instead of:
- code = key.unpack('c')[0] # using unpack to be compatible with
1.9
it should be (C - unsigned int)
+ code = key.unpack('C')[0] # using unpack to be compatible with
1.9
------------
I cannot verify this due to something extremely baffling to me:
in IRB,
ASCII = (0..255).map{|c| c.chr }
PRINTABLE = ASCII.grep(/[[:print:]]/)
PRINTABLE.length
>>> 191
However, inside the ruby program PRINTABLE.length only gives 95 !! ???
#!/opt/local/bin/ruby
ASCII = (0..255).map{|c| c.chr }
puts(ASCII.length)
PRINTABLE = ASCII.grep(/[[:print:]]/)
puts(PRINTABLE.length)
So the alt-codes are lost. I am using the same terminal for both. I am
using the same ruby interpreter in the sample program, as the one irb is
using.
Can someone tell me why the grep command returns a different result in
irb vs a ruby program ???
Nit Khair
> Michael Fellinger wrote:
>
>
> However, it does not accept/print the Alt-keys - is that deliberate, or
> did have you not looked into it.
>
> I have had problems with alt-keys (since they generate 2 bytes and that
> goes thru my getch() loop twice, often leaving an extra char in the edit
> field.
manver, I have figured out one thing about alt keys. To do this i had to
make: PRINTABLE = ASCII
until someone can tell me why irb != ruby.
In osx, there is a terminal option "Use alt as meta key". Now "alt"
gives me the same result as using Esc. So now, alt-a and Esc-a will both
generate "M-a".
Without this setting, alt-a gives 165, alt-b = 171, alt-c = 167 which is
not contiguous, and generates some junk chars.
So now i've basically duplicate esc and alt. But i accidentally
discovered something ... I can press "Esc ^A", or "Alt ^A" so i do have
a bunch more of keys i can map! Hope there's nothing more i've missed.
Your file keyboard.rb rocks, please make it a gem, so others CUI
programmers can benefit from it. Preferably standalone.
Nit Khair
> Nit Khair wrote:
>> Michael Fellinger wrote:
>>
>
1. it returns strings. If you use ncurses form drivers these take
integers. So one has to convert the value sent to an int to avoid
errors.
So typically in the start of the press method, I have done:
ret = ret[0] if ret.length == 1
ret = 32 if ret == 'space'
Even then one has to watch out for others that are not single length
tab/return/bs/ etc.... will have to check for others. Some of these are
separately handled in the case, such as tab and return so thats okay.
Others such as backspace and delete etc which were passed straight to
the driver, need to be watched out for.
2. You check for @stopping? inside the while char loop immediately after
while.
To me this means that after the user has entered the Exit key, he still
has to press one more key to actually exit. I've put the break before
the end of the loop. Would like you to confirm this.
Charles Oliver Nutter
> So, I changed platform.rb to :
>
> - when /i?86|x86|i86pc/
> + when /i?86|x86|i86pc|powerpc/
>
Can you submit this to Ruby FFI, as a bug or on the mailing list? I'm
not sure Wayne Meissner monitors ruby-talk.
> Forgive me for being spoilt, but is there some script that takes a
> header file, or C source and generates the attach_function lines ?
There's some generation logic for at least struct layout, but I'm not
sure if it does general function wiring. It was written by the Rubinius
guys, and there's not a lot of documentation for it I could see. Good
idea though.
I expect we'll see a flurry of fully-wired FFI-based libraries getting
released one after another very soon here, and each library is one less
library to wire.
- Charlie
Nit Khair
>>>
>>
manver, I mentioned to your earlier that I am intending to use
keyboard.rb of the ver project.
I have also been studying keymap.rb and its associated programs so i can
get more keys like in vi and emacs. However, I understand these classes
in chunks but can't piece it together.
Wondering if you can give a small example that installs and uses keys
using these classes so i can use it. I am finding myself having to
reinvent the wheel since I am unable to grasp the code of ver.
Thanks in advance.
Michael Fellinger
>>>> Michael Fellinger wrote:
>>>>
>>>
> manver, I mentioned to your earlier that I am intending to use
> keyboard.rb of the ver project.
>
> I have also been studying keymap.rb and its associated programs so i can
> get more keys like in vi and emacs. However, I understand these classes
> in chunks but can't piece it together.
>
> Wondering if you can give a small example that installs and uses keys
> using these classes so i can use it. I am finding myself having to
> reinvent the wheel since I am unable to grasp the code of ver.
Hope this helps:
http://p.ramaze.net/10515
Sorry, it's quite late here, can't go into more explanation for now.
And yeah, the code is quite hard to grasp, i'm not going to change it
anymore though since it works really well for what i need, the main
difficulty is with the keymapping but i couldn't come up with anything
more elegant, the Keyboard is tied to the VER concept a bit as well,
but you should be able to improve on that easily.
^ manveru
Nit Khair
> On Mon, Nov 10, 2008 at 12:16 AM, Nit Khair <sentin...@gmx.com>
> wrote:
>> Wondering if you can give a small example that installs and uses keys
>> using these classes so i can use it. I am finding myself having to
>> reinvent the wheel since I am unable to grasp the code of ver.
>
> Hope this helps:
> http://p.ramaze.net/10515
>
head around this.
Cheers.
Nit Khair
> Michael Fellinger wrote:
>> On Mon, Nov 10, 2008 at 12:16 AM, Nit Khair <sentin...@gmx.com>
>> wrote:
>> Hope this helps:
>> http://p.ramaze.net/10515
>>
manver,
I have got the above sample working (after making some corrections. e.g.
let is not a method is was map. and map should be key.
Not sure if my corrections are correct, they are based on vi.rb.
The sample prints all keys, including Esc combinations, but does not use
C-c as a control, although the mapping is there.
key :esc, :into_control_mode
key 'C-c', :into_control_mode # esc is slow due to timeout
I also did this:
VER.map :control do
key 'C-q', :stop
key 'q', :stop
key 'r', :close
end
I assumed that under C-c I could press C-q or q or r. But these are not
mapped to C-c or Esc.
Any tips on what to do for C-c would be great.
Thanks a lot.
p.s. I have attached the file I modified from the link you gave me as
test.rb.
Attachments:
http://www.ruby-forum.com/attachment/2909/test.rb
Michael Fellinger
> Nit Khair wrote:
>> Michael Fellinger wrote:
>>> On Mon, Nov 10, 2008 at 12:16 AM, Nit Khair <sentin...@gmx.com>
>>> wrote:
>
>>> Hope this helps:
>>> http://p.ramaze.net/10515
>>>
> manver,
> I have got the above sample working (after making some corrections. e.g.
> let is not a method is was map. and map should be key.
> Not sure if my corrections are correct, they are based on vi.rb.
Pull from the repo, there have been major changes and improvments to VER.
Nit Khair
> On Mon, Nov 10, 2008 at 4:57 AM, Nit Khair <sentin...@gmx.com>
> wrote:
>> let is not a method is was map. and map should be key.
>> Not sure if my corrections are correct, they are based on vi.rb.
>
> Pull from the repo, there have been major changes and improvments to
> VER.
Nit Khair
> On Mon, Nov 10, 2008 at 4:57 AM, Nit Khair <sentin...@gmx.com>
> wrote:
>> let is not a method is was map. and map should be key.
>> Not sure if my corrections are correct, they are based on vi.rb.
>
> Pull from the repo, there have been major changes and improvments to
> VER.
manver.
I integrated your example into one of my programs. (Works fine. Changed
VER.stopping and VER.info the @focus.stopping and view.info.)
I was trying out the n-action feature: e.g 3j 10j etc.
It works fine for single digits but when i try double digits, i get:
No mapping for ["1", "2"].
I tried combinations such as :
> map([/^(\d\d?)$/, 'k']){ @arg.to_i.times {view.up}}
> or \d+ etc.
But apparently the stack reads one digit, and goes into ready().
1. I just want to check if multiple digits work with you, am i doing
something wrong.
2. I would like to know if you modify or improve/debug this further. Is
there some list or webpage for "ver"?
Thanks a lot for your help.
Michael Fellinger
> Michael Fellinger wrote:
>> On Mon, Nov 10, 2008 at 4:57 AM, Nit Khair <sentin...@gmx.com>
>> wrote:
>>> let is not a method is was map. and map should be key.
>>> Not sure if my corrections are correct, they are based on vi.rb.
>>
>> Pull from the repo, there have been major changes and improvments to
>> VER.
>
> manver.
> I integrated your example into one of my programs. (Works fine. Changed
> VER.stopping and VER.info the @focus.stopping and view.info.)
>
> I was trying out the n-action feature: e.g 3j 10j etc.
> It works fine for single digits but when i try double digits, i get:
> No mapping for ["1", "2"].
> I tried combinations such as :
>
>> map([/^(\d\d?)$/, 'k']){ @arg.to_i.times {view.up}}
>> or \d+ etc.
>
> But apparently the stack reads one digit, and goes into ready().
>
> 1. I just want to check if multiple digits work with you, am i doing
> something wrong.
Yeah, it has to be:
map([/^\d$/, /^\d$/, 'k']){ @args.join.to_i.times{ view.up }}
which is a PITA, so i made a shortcut for it, see below
> 2. I would like to know if you modify or improve/debug this further. Is
> there some list or webpage for "ver"?
I fixed that just today, check it out :)
http://github.com/manveru/ver/commit/9fb04aa943e03850c19b0352b519d885826e7f44
^ manveru
Nit Khair
> On Tue, Nov 11, 2008 at 12:28 AM, Nit Khair <sentin...@gmx.com>
> wrote:
>> I integrated your example into one of my programs. (Works fine. Changed
>>
>> 1. I just want to check if multiple digits work with you, am i doing
>> something wrong.
>
> Yeah, it has to be:
> map([/^\d$/, /^\d$/, 'k']){ @args.join.to_i.times{ view.up }}
> which is a PITA, so i made a shortcut for it, see below
>
>> 2. I would like to know if you modify or improve/debug this further. Is
>> there some list or webpage for "ver"?
>
> I fixed that just today, check it out :)
> http://github.com/manveru/ver/commit/9fb04aa943e03850c19b0352b519d885826e7f44
>
> ^ manveru
I've only integrated the count_map as yet.
Absolutely brilliant. Works like a dream :-D
Nit Khair
manver,
macros were not working for me. Are they working with you?
I traced it down to the line in keymap.rb
> @keys << Key.new(*args, &block)
where the key was created but not getting inserted into @keys.
Finally, I found that key assignments, when inspected, show "e" (for key
e), whereas a macro for e will show ["e"].
So i tried flattening and its worked out. Don't know the impact of this,
though.
def map(*args, &block)
if block_given?
> args.flatten!
> @keys << Key.new(args, &block)
else
self[*args]
end
end
btw, the sample vi.rb that you gave has the count_map lines for up and
down mapped incorrectly (up is mapped to down, and vice-versa)
Thanks.
Nit Khair
> I fixed that just today, check it out :)
> http://github.com/manveru/ver/commit/9fb04aa943e03850c19b0352b519d885826e7f44
>
> ^ manveru
Manveru
I have a question regarding the scope of the keybindings. Being new to
ruby am confused.
Are these done in a global/application scope. I mean :
> @keyhandler = VER::KeyHandler.new(self)
> VER.let :insert do
> map(/^([[:print:]])$/){ view.show(@arg) }
Here, i have defined a key handler, but i don't see an object for my key
mappings.
My application is slightly different from vi - its multi-screen. Take
alpine e.g. Each screen has its own mappings. I go from menu, to screen
A, then screen B, then back to menu. All objects in screen A are
released so the mappings too are. Thus each screen has its own bindings
mappings.
Am i correct in thinking that as per VER, my entire app would have to
share the same bindings?
thanks.
Michael Fellinger
No, mappings are done per mode, and the handling is done via Keyboard,
where you assign the object you want to send your keys to via focus=.
That means, if you go to a menu, menu has to get focus and it should
have a mode, like :menu. Then the mappings from VER.let(:menu){} are
used, those might give focus to another window, which has a mode like
:window...
So bindings are bundled into modes, and if you switch the mode you get
different bindings.
You can also inherit bindings from other modes to keep things DRY, like this:
VER.let :foo do
map('f'){ view.show('from foo') }
end
VER.let :bar do
map('b'){ view.show('from bar') }
end
VER.let :duh => [:foo, :bar] do
map('d'){ view.show('from duh') }
end
This would give :duh the mappings f, b, and d, while :bar only has b
and foo only has f.
All of the blocks are instance_evaled in the scope of KeyHandler,
which provides the possibility for shortcuts to view or other
convenience-methods.
So if you have a view like this:
class Foo
attr_accessor :mode
def initialize(message)
@mode = :example
@keyhandler = VER::KeyHandler.new(self)
@message = message
end
def hello
window.printw(@message)
end
def other(message)
Keyboard.focus = self.class.new(message)
end
def press(key)
@keyhandler.press(key)
end
end
you can do following:
VER.let :example do
map('h'){ hello }
map('o'){ other('From Russia, with love') }
end
Keyboard.focus = Foo.new('Hello, World!')
Please note that I didn't really run the code above, but it should
work like that in case i didn't mess up something real bad.
I know that this is quite some overhead, but VER is highly dynamic in
regards to keymappings, just about any key can switch to a different
window, view, or mode, the keyboard focus changes quite often as well.
I also didn't intend this to be used by some other application, so
some of the implementation is quite specific to VER and i'm not sure
how it would work out in another context.
If you have further issues, please consider forking the project and
work it into a shape that suits you better, possibly a library that
VER and your project and just about any app based on ncurses can
share. Handlings keys is a PITA, and this really is just the usually
piling of layers of abstraction, which I don't like, but it seems to
be the only way until someone comes up with a unified way of handling
those keys (maybe next generation terminals in the year 2100).
This also has no handling of unicode yet, which I will need soon, so
no idea how the API will change by then.
^ manveru