2009/3/17 Youness Alaoui <kakar...@kakaroto.homelinux.net>: > > Great! Nice to see you work so fast! I just tried it out and it does work > already! although.. the contact list didn't appear.. butI know you already > know that :)
It's just that I love python, I find it so easy to get going with development... > by the way.. I just realized you are kjir from IRC... sorry about my > previous reply to you.. I asked about logging in amsn2 and I thought you > meant 'chat logs', not debug logs, hehe... Don't worry about that, I know that you get asked a lot of silly questions and it's not always easy to recognize legitimate ones ;) > actually, the logging mechanism is something that comes from pymsn, look at > the code that sets the logger, I'm sure there are many more options that you > can do with it.. > for now, amsn itself doesn't have any logging mechanism.. if the one that > pymsn uses is a standard python lib, then we could use that too! The reason I asked about that is that with the ncurses interface print statements interfere with the program display, so I have to redirect output to a file. Also I learned a long time ago that a good logging mechanism is an invaluable tool when it comes to debugging... Maybe it's more true for web development, but it's always helpful. Anyway I'll give it some thought, maybe I can come up with a nice system to do logging. > Very interesting point here! I didn't think of the hotkeys yet! I wonder if > we should stick with amsn1's hotkeys (not a lot I must say) or just start > from scratch... I wonder also if we should have a common hotkey list or > every front end could implement its own... I really don't know yet.. Well some hotkeys should follow some standars, like ctrl+w to close a tab, so that we apply the rule of least surprise > but > quickly off the top of my hat I'd say: > amsn would provide a 'HotKeyView' with hotkeys for all actions, and the UI > would have to use them ... like a list of KeyBindingView and Action (Action > being a callback to call, and KeyBindingView already exists in > amsn2/core/views/keybindingview.py > Those would be configurable with an option like 'vim hotkeys/emacs > hotkeys/custom' so a user could override and customize each hotkey, and so > nothing would have to be done by the UI... keeping our "dumb UI" design.. > you just get the hotkeys for every window opened, you hook the key binding > to call that specific action... (since the core sets the bindings on each > window, we would have the callback contain all the necessary arguments > already.. like "view_history $email".. if the core detects that the user > switched to another tab, he would just change the action associated with a > binding and call the SetHotkeys again on the window, with the other user's > email as argument, etc... ) This could be a good idea, although I am not so convinced about the mechanism to pass the correct arguments. Maybe all callback functions must accept a single argument which holds a "context" object where you can find the info relative to the selected tab (i.e. the user's e-mail), so that functions that need it (i.e. nudge the user) use that object, functions that don't just ignore it. The thing is some hotkeys will need to perform actions on the UI itself (i.e. enable/disable bold, hide user pic), but we could solve that by creating those methods in the base classes and setting them as the callback function. > This would allow all front ends to have the same key bindings, so we could > actually finally ue amsn wouldn't the need to use the mouse at all (use > ncurses key bindings on the gtk/qt/efl front end for example, hehe). And > would allow users to customize their stuff.. I have some doubts about the vim style keybindings in a graphical UI, you'd need to find a way to have at least two modes (insert mode and command mode) and make it understandable to the user in which state he is. It not impossible, though, Vimperator is an example of such an application. > The front end could however provide the core with a 'PreferredHotkeys" for > each action, in case some front ends have some kind of preference (like, > switch tabs with ctrl-up/ctrl-down on qt4/kde because it's the same as > konqueror or whatever, but ctrl-up/ctrl-down might be the default gnome > binding to switch from previous/next virtual desktop... (just examples, I > don't use kde or gnome so don't know the real shortcuts)). If the user never > customized the shortcut, then the core would store the front end's > preference as the default one. Yes this is a good idea, as above this would apply the rule of least surprise ;) > hehe, thanks! :) yes, i'm very proud of the design! :) > You can start looking at these two threads if you want to understand the > design : > http://thread.gmane.org/gmane.network.instant-messaging.amsn.devel/9502 > http://thread.gmane.org/gmane.network.instant-messaging.amsn.devel/9497 > It's a bit old so some stuff might have changed but I think the general idea > is there.. I should probably start a wiki page on the design and keep it up > to date as we move along... also keep the API well documented! > You can comment on the design whenever you want.. especially if it's to say > how incredibly good it is.. :D :) :p I read the messages and now I understand what views are (well sort of ;) ). There are two issues that come to my mind right now: with ncurses you can't display images, but you'll probably want to display the corresponding text for the smileys and the contact list should always display just the nickname because with ncurses you have less control over the spacing, so it's better with shorter names. I don't know the details about the implementation of these aspects (yet) so maybe these issues don't really exist, I'll have to check... Does this design allow for a "disable smileys" toggle? Because I don't know about you, but I sometimes have to fight hard with smileys to understand what it is written because often people map smileys to small words that may be embedded in other words. Ok I'll explain it with an example: let's say you map the word "ace" with an image of an ace of spades, then when you write word as "space", "grace", "mace", "face", etc you see some letters and the smiley without understanding what the word actually is. I know, this is a silly mapping, but it's not so uncommon, at least among my contacs :O What I like about this design is that it is very flexible and I can see an easy solution about any issue that arises :D This is very valuable! -- Stéphane ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
