2007/1/20, Youness Alaoui <[EMAIL PROTECTED]>:
>
> On Fri, Jan 19, 2007 at 10:20:45PM +0100, Karel Demeyer wrote:
> > I'm going to answer inline before reading it all. I might not read it
> > all yet as I'm tired and about to sleep.
> >
> me too, bus in 5minutes..
>
> > 2007/1/19, Youness Alaoui <[EMAIL PROTECTED]>:
> > > I'll try to be brief because I'm at work, but if you need to talk about
> > > this more or you need me to explain better something I
> > > said, you can lways do it by PM.
> > >
> > > On Fri, Jan 19, 2007 at 05:53:36PM +0100, Karel Demeyer wrote:
> > > > After a power shortage of 24 hours, let me make something clear:
> > > > I never said "aMSN is going to use my thing !", nor did I say we
> > > > shouldn't let the user choose, I said I wouldn''t like another pop-up
> > > > but I didn't demand this. I'm not a dictator. You say I'm not in for
> > > > compromises ... well, I just code what I like ... as most ppl here
> > > > didn't say "I'd never want the inline spaces", I started doing
> > > > something, noone started on the cards, after there are cards, you can
> > > > have the user choose. Even if you come up with a third solution, let
> > > > it be. If everyone is sure my idea is bad and expresses it that way,
> > > > I'll remove everything I committed and make a plugin for myself alone.
> > > > You asked why I started doing it in the drawContact proc ... well,
> > > > because this was my idea and nobody stated clearly this shouldn't be
> > > > done inside that proc. It seemed easier to me to do it there and it
> > > > was just where I started. All things drawed related to contacts are
> > > > in that same proc ... ok, always reading that code I put in could
> > > > generate too much cpu-wotrk for nothing you think. Changing it is
> > > > simple.
> > > >
> > > first, we're not here to make a war, there has been enough flame wars in
> > > the past and we all know how it can be bad to start a
> > > new one here. I didn't say you're a dictator, just saying that you leave
> > > no place for compromise, you get an idea about
> > > something 'usable' and you think it's the only best solution possible.
> > > About you just code what you like, I agree and that's
> > > perfectly normal, I can't tell you to code something you don't even want!
> > > so there shouldn't be any regret in coding it your
> > > way and I know that if I wanted it to be ccards I would have coded the
> > > ccards myself too and that's probably what I'm going to
> > > do once I get the time for it. Your idea is not bad, and I never said it
> > > is bad, I always said it's a good idea and I'm sure
> > > many people will like it, but :
> > > 1 - I don't really like it
> > > 2 - it is far better in usability terms, but worse in 'expectations' terms
> > > 3 - from a point of view of a WLM user, a ccard is far more usable than
> > > that, because he is used to it.
> > >
> > > I didn't say don't do it, I just said make it a choice and the popup is
> > > nothing special it's a one time thing, so a WLM user
> > > who wants to keep his habits can choose the ccard and a pure amsn/unix
> > > geek or whatever will choose (jabber:p) the inline
> > > thing.
> > > You don't need to remove your code or put it as a plugin, it's in the
> > > core and it will stay that way (until Phil starts a
> > > revolution about the fact that it needs to be in a plugin)...
> > >
> > > About the code position, I clearly said that it should be done inside its
> > > own proc to allow for modularity and reuse of that
> > > same code. Allowing us to draw the info either inline or in a ccard
> > > (didn't you get the mail?)
> > > The fact that you went and did it in drawContact instead of modularizing
> > > it like I said was an offence to me, as if you did
> > > only what you wanted and not wanting to allow ccard to coexist with your
> > > idea. I might haave been off about that (stressful
> > > week)
> > Well, in my local copy, the code is already in it's own proc inside
> > gui.tcl. I didn't commit it because I'm waiting for Phil's commits.
> > It really doesn't take me too much time to put it it's own proc as I
> > still have to rewrite things on and on... It was only for testing
> > purposes I put it in guicontactlist.tcl. Just for making it easy for
> > myself as all the code where it depends on is just above it in that
> > same file. I didn't want to sound arrogant by placing it there. You
> > wanted a var to choose between the both, but there was only 1 choice
> > yet, so I made it a var to draw the spaces inline or not, with a
> > comment that told about how I'd like it but it's still experimental
> > code (I said this in all commits, like "experimental" or "just
> > testing"). Nothing is rock solid in any of these lines ...
> >
> > >
> > > > If the result of this poll is negatoive for me, if most ppl dislike
> > > > it, and I want you to be honest, I'll just remove it, I won't be angry
> > > > about that. It just seemed like I was the only one doing something
> > > > about drawing spaces info.
> > > >
> > > As I said, there's no need to remove it, cause I approve it myself, the
> > > idea is good, what I don't want is for it to be forced
> > > upon our users, they have to make a choice and they should be able to get
> > > the ccard if they want to.
> > > The poll is already going in your favor, so I guess this is already out
> > > of the question, right ?
> > Look, you found it a bad idea to put the ccards in a plugin. And I
> > won't be angry if they come in the core, I just created the code the
> > way I liked it, so you could see what I meant (cause that's not always
> > clear) but nothing said it couldn't be changed. If someone puts in
> > ccard code it won't take long to change that var. Creating it already
> > for what has to come isn't very succesfull as it will have to be
> > changed anyway ...it's always the same with software, no ? :)
> > You want ccards in the code because you think users expect this.
> > Well, I wouldn't want this, but, shouldn't we enable the
> > doubledisplaypicture plugin by default then too ? Or put it that way
> > in the core and having a plugin/option to remove it ?
> >
> actually, dualdisplaypic is aimed to be one of the core plugins, I remember
> we discussed it and it was decided
> that it needs to be core plugin ,I just never had time to take care of that.
> I would also like to have some kind of assistant on the first run (when a
> profile is created or soemthing) that
> would guide the user through customizing his amsn look & feel. dualDP,
> inline/ccard, webcam/audio, etc.. just
> like emule, or azureus or msn plus! or any other program of that type always
> ask for a 'first time
> configuration' wizard. But we just don't have enough material for it so far,
> which is why I kept this idea for
> some other time in the future.
I feared someone (besides me) would come up with this idea. I had
this idea too, but I think it's not that good. Although it's only run
once when you install the program, it's really annoying IMO, and it's
the first thing some users see of the program. At the other side, for
some users it might be a good thing as we can show off what our
program is capable of. It shows we have A/V if we ask 'm to set it
up. It shows we have ccards if we ask that etc. So, I'm not pro, but
I see some positive things. Let's debate this ?
>
> > >
> > > > I don't know anymore what I was going to say more, if I remind, I'll
> > > > say it later. I just read this mail and it seems like you "insult"
> > > > (this word is too heavy though) me for a dictator. I want to make
> > > > clear I don't want to be seen like one.
> > > >
> > > no, I never said that you were a dictator, you can't dictate what to do,
> > > you have every right to code it the way you want since
> > > you're the ne doing the commits, but the fact that you didn't leave any
> > > room for negociations on how to do it best is what I
> > > disliked.
> > Well, I think you have a bad idea about me. I sure am open though I
> > do my best to convince you of what I'd like to see. How can I convinc
> > you without code ? If I wanted to change some aspect in Gnome for
> > example, I'll have to write code to demo it; a mockup won't do.
> > > Just like the option, I said make it use a variable to know whether it
> > > should draw like this or like that and you
> > > went and use a variable for either enabling or disabling the sapced thing
> > > and you put in comments 'a plugin can put it to 0 if
> > > you want to add ccard', which was like "if you want something do it as a
> > > plugin, but this inline thing will be the 'main'
> > > feature" without having everyone's opinion on this.
> > Cfr supra, it was not meant to be "unchangeable" or whatever, more
> > like a demo of what I thought. I expected you to tell "well no, it's
> > not good" and if most ppl think this way I'd change it immediately.
> > But now we have only 1 implementation so I'd better have a var to
> > disable it then one to choose between this and something that doesn't
> > exist yet ...
> > > Dictator is not the word, I would rather use 'arrogant'. Thinking your
> > > idea is better than anyone's.
> >
> > It's sounds hard for me, but I understand why you feel so, I think.
> > I hop I'll sound more humble in the future, but I just thought I had
> > to implement it "my way" first to show what I thought. The words in
> > my comment above that code sound a bit wrong, I understand. It was
> > more meant like "See, if we would do it this way, it would work this
> > way"...
> yeah, sorry if I was hard on you, it's just the way I felt. It might have
> been because before this issue I was
> already pissed at how you answered phil on a commit log, you committed
> something buggy which screwed up the new
> contact list and he fixed it all and wrote in his commit log (r7773) what he
> fixed and added :
> "Next time please do a cleaner code..."
> which is totally legitimate,
I felt enormous pissed that day. I found Phil's log very arrogant and
that's why I answered that day. Phil didn't talk to me. He changed 3
things just after my commits without asking me something or saying
something. If he would have told me anywthing I would have understand
it I think. It was still work in progress. And the main thing Phil
did, was renaming a tag. "main_part" instead of "clickable". Ok,
clickable was a bad name, but I just added that tag as it was needed.
I planned refactoring the code in drawContact again as I already did
some times, it was not code that was locked till a release, right ? I
found it harsh because most of the code in guicontactlist.tcl was done
by me ("most" doesn't mean there was a LOT done by others) and it
seemed like phil didn't like my code anyway so I felt mistreated.
If anyone feels like they have to change my code after every commit of
mine, please TELL ME.
>but in your next commit, you put in the commit log (r7775) :
> "Is this 'a cleaner code' ? If it ain't clean enough I'll forget about a
> 'next time' ..."
I felt that way, sorry. Phil was like insuling me of writing bad code
while he also made a (ok, very small) mistake. Everyone makes
mistakes, please don't punch me for this.
For me it was like Phil was talking to me as if he's the boss and I'm
a stupid disciple. I thought we didn't have hierachy, although I will
freely admit I'm the one with the least coding-experience and possibly
one of those with the least TCL/TK-knownledge. I'd like to learn, be
it some "hard way", but not this way.
> and I found that so arrogant, that's what pissed me off at first, maybe that
> feeling stayed and it ignited the
> way I perceived your comments afterwards.
>
> > >
> > > > "why do you want your idea in the core and my idea only as a plugin?"
> > > > is because I want a very usable aMSN, and my idea seemed better
> > > > usability-wise, and I thought you wanted ccards just to be able to
> > > > "clone" WLM. I didn't know you *hated* this inline idea. Also, this
> > > > was *just an idea*, I started doing it this way because noone was
> > > > forbidding it and noother was doing anything else. I did it because I
> > > > thought "well, If I'm not gonna do it, noone else will do it" and I
> > > > kind of hoped you'd like it afterwards. seems not, well, no problem
> > > > for me. It will only demotivate me for a while, but I won't be angry
> > > > or whatever.
> > > >
> > > I never said I hated your idea, I just said it didn't seem right.
> > > Usability, yes, it's a good thing to do, but usability
> > > DEPENDS on the person, always. the HIG is just a guideline, it's not a
> > > law, so we may or may not follow the guideline it says,
> > > it all depends. In amsn's case, this is a very special case, the contact
> > > list has a function and it should only provide that
> > > function, there is no HIG about how to create 'contact lists', we already
> > > discussed that. Also, what makes amsn special in that
> > > matter is te fact that it's a clone of another product. If that other
> > > product doesn't follow the HIG, then it means we have the
> > > choice of either choosing usability in the point of view of the HIG, or
> > > usability in the point of view of what users accustomed
> > > to WLM will find more usable for them.
> > > You say you hoped I'd like it afterwards. I do, I always liked it, but I
> > > still prefer ccards. I think that it makes the CL
> > > really bloated, ever tried to open 10+ inline spaces ? how does the CL
> > > become ? it becomes really really bloated, not nice to
> > > look at, you can't just parse your CL with a look and see your contacts..
> > > that's what I don't like. Also, with WLM, you could
> > > only open one ccard at a time, so you click on your users and directly
> > > see their card, the 'ccard' toplevel being replaced each
> > > time (without flickering or anything) then when you finish, you just
> > > close it.
> >
> > I didn't know about this, sounds interesting (though I still prefer inline
> > ;))
> >
> yeah, it's all a matter of taste and 'les gouts et les couleurs ne se
> discutent pas' (I can't remember the
> sentence in latin :p)
"de gustibus et coloribus non disputandem est" (I don't want to sound
arrogant, it just came up)
>
> > > now, with your inline spaces, you need to open
> > > AND close the spaces info for each user you look at
> >
> > > Also, as you said, your eyes and mouse are moving down, so you click, it
> > > shows down, you will usually move your mouse to the
> > > center of the info, then when you want to close it, you need to go back
> > > up, it can et distracting for some users, also, it is
> > > in the upper left corner, not right corner and that's even more
> > > disturbing. + the 500 ms delay for it to show up/disappear is
> > > frustrating (this is caused by the redraw events being queued recently,
> > > I'll talk about it laater).
> > > While with a ccard, you click, the ccard appear, first, it's a change in
> > > your screen so you notice it right away, it may be a
> > > bit disturbing at first because of the reasons you pointed out before
> > > (you need to refocus your eyes and everything), but then,
> > > you get a good window with information needed, you click on a user in the
> > > cl, the info is updated right away, how nice! once
> > > you're done, you click to close it and you already know where to click,
> > > it's stored in your memory.
> >
> > So the ccard opens at the same spot for every user ? I'll test this on
> > a windows PC once as I don't know about this. Reading this, I see
> > ccards have some pro's too, don't take me wrong, I'm going to admit
> > it. But still, I'm more in favour for the inline ones
>
> yeah, well, when you first open it, it can open anywhere, but it's always
> next to your pointer iirc, then when
> you select a user in the CL (don't forget WLM allows you to click and select
> a contact) the ccard changes
> automatically to represent the ccard of the 'currently selected user', you
> also can't open two ccards, only one
> at a time, if you try to open a second one, the first one will just update
> itself.
>
> > >
> > > concerning the 500ms delay I was talking about, it's because you added a
> > > queue for redraw events, it's good, but I think it
> > > should only apply to protocol events, for example a psm change, status
> > > change, etc.. all that, I agree, should be queued, but
> > > when a user clicks somewhere and that causes a redraw, it should be
> > > instanttenuous because it's user interaction, he needs to
> > > see the change right away, so I ws thinking about maybe adding a list of
> > > events to queue and only queue those, or events to
> > > execute right away and that would flush the queue..
> > > I told Phil, don't know what he thinks, tell me what u think..
> >
> > Well, when we register events, we now register for "all" sources.
> > Maybe should make it possible to have a "all minus protocol" option
> > there or something and register once for protocol, once for other
> > sources and give the proc we assign to event to an extra var,
> > depending on the source ? Or maybe we should just add the source to
> > the vars sent with the event ?
> >
> >
> well, I don't know what event is sent to ask the CL to redraw the contact
> when we click, but it should be
> something like :
> ::fireEvent gui contactSpaceShown drawContactqueue
>
> and we should do in the drawContactqueue :
> # blablab add to queue
> if { $event == contactSpaceShown } {
> FlushQueue
> }
>
> or..
> # blablabla add to queue
> if {$source == "gui" } {
> FlushQueue
> }
>
>
> > >
> > > > About why I didn't do the "draw stuff on canvas" thing in another proc
> > > > yet .. well , it's just the way I do things. As long as noone seems
> > > > to just create the contactcards so I have another use-case for that
> > > > proc, I do it the simple way. It's not that much work to move it over
> > > > to another proc. I also started on this inline drawing just as a
> > > > test, to see if my idea was possible. It's not that much work to
> > > > remove it, and if you want to, I'll just remove it.
> > > >
> > > not modularizing code is not really 'the simple way'. Anyways, I think
> > > Phil refactored everything now, we'll see how it works
> > > out.
> > >
> > > > I'm also going to respond to that other mail: I already used the
> > > > ::hotmail::got_URL proc, it was changed over time.
> > > >
> > > ok.. but is it still not working ? I tried and it doesn't work, so it's
> > > weird.. do you think the .html file is not good ? or
> > > that maybe the gotURL is wrong ? maybe that's why some people report they
> > > can't access their profiles... maybe the auth is done
> > > in a wrong way...
> >
> > I don't know about this. I asked vivia once but then I found the
> > gotURL proc and it seemed to work for me.
> >
>
> it worked for you ? not for me.. so I suppose that's the problem, it's not in
> the URL we receive (vivia knows
> the bug), it's in the file or the proc, the auth+redirection doesn't work
> correctly. this bug was first known as
> 'some users' when you click on the profile of a user, it sends you to hotmail
> login page.
>
> anyways.. I missed the bus, so... bye
>
> KKRT
>
> > >
> > > KKRT
> > >
> > > > Karel.
> > > >
> > > > 2007/1/18, Youness Alaoui <[EMAIL PROTECTED]>:
> > > > > On Thu, Jan 18, 2007 at 03:14:06PM +0100, Karel Demeyer wrote:
> > > > > > 2007/1/13, Youness Alaoui <[EMAIL PROTECTED]>:
> > > > > > > Hello hello...
> > > > > > > ok, now I remember your mockup! but let's start with NWM's mockup
> > > > > > > : bad idea, too big, no more CL available, the
> > > > > > > way yyou did it is good, but as a separate window.
> > > > > > >
> > > > > > > now about Karel. I must say, I didn't like it at all. well, I
> > > > > > > still don't for one main reason : in your mockup
> > > > > > > those photos/blog posts are from your contact "Vivia", but I know
> > > > > > > vivia doesn't have any space :p
> > > > > > > no, seriously, my main concern is that the CL is a CL, it's a
> > > > > > > contact list, to see your contact and allow you to
> > > > > > > interact. When you were saying the ccard is bad, I thought 'you
> > > > > > > may be right, it's too small, clustered, etc.."
> > > > > > > but I thought the idea would be to have an 'informational window'
> > > > > > > just like the properties window when the user
> > > > > > > can clearly see the info he wants. I didn't think you were
> > > > > > > talking about an embeded thing inside the CL.
> > > > > > > Your idea, for me at least, is not good because it renders the CL
> > > > > > > as something else, it doesn't become a
> > > > > > > "contact list" but a "contact/information list". To me, this idea
> > > > > > > would be analog to clicking on the "you have
> > > > > > > 10 new messages in your inbox" button and the CL expands to show
> > > > > > > you all your emails... the CL is not a
> > > > > > > browser...
> > > > > > > it's like a dispatcher, it's there to give you QUICK ACCESS to
> > > > > > > your contacts, their status and your inbox count.
> > > > > > > Having that extra info is not in the 'philosophy' of a contact
> > > > > > > list.
> > > > > > > I hope I got myself clear enough...
> > > > > > Well, if you really mean that's the only use for out contactlist,
> > > > > > then
> > > > > > why do we show the music contacts play and how they feel (psm)?
> > > > >
> > > > > The PSM is part of the user information, it can be "in the shower" or
> > > > > something, so it is usefull when looking
> > > > > at the CL.
> > > > >
> > > > > > >
> > > > > > > now, I didn't take too much time in reading your posts because..
> > > > > > > well, no offense, I just didn't feel like it :)
> > > > > > > I did read them though but didn't spend much time on trying to
> > > > > > > understand every dot and commas. The good news is
> > > > > > > that your idea is not that 'bad', it just doesn't fit in the
> > > > > > > philosophy of the CL (in MY opinion) BUT it is 100%
> > > > > > > very good in terms of usability (without considering the fact
> > > > > > > that the user might say 'wtf is this doing here').
> > > > > > > Your point about how to rescan the screen, the direction of the
> > > > > > > parsing of the list, the availability of the
> > > > > > > info, etc.. I think it all makes perfect sense, the problem is
> > > > > > > just that I don't know how the users would react
> > > > > > > to that... I personally would say I prefer a ccard.
> > > > > > >
> > > > > > > If we go back in time a little, go back to the early days of my
> > > > > > > participation in this project, I remember we had
> > > > > > > some kind of rule : for EVERY new feature, make it optional, for
> > > > > > > everything that may be done 2 ways, make it an
> > > > > > > option...
> > > > > > > actually, it was more of a customization thing and answering
> > > > > > > every user's needs so you must be able to customize
> > > > > > > everything your way, if a user asks for your mockup, we do it but
> > > > > > > as an option, someone asks for a ccard, we do
> > > > > > > it but as an option.
> > > > > > > What I would like to propose is to have it both ways. The ccard
> > > > > > > is really easy, it can be done in a few minutes,
> > > > > > > I'm sure, I mean the whole code is there already, all we need to
> > > > > > > do is, when inserting the data in the ccard,
> > > > > > > add a few lines where we insert additional infos like blog posts
> > > > > > > and such.
> > > > > > > Your idea would take a bit more time I would guess, right ? but
> > > > > > > it won't take too much either.
> > > > > > > Hummm... I just noticed something, in your mockup, you have that
> > > > > > > photos/ blog posts thing, and it looks exactly
> > > > > > > the same as how it should go in the ccard, and the new CL is a
> > > > > > > canvas and the ccard is probably also a canvas,
> > > > > > > so we could have a proc :
> > > > > > > proc buildSpaceInfo { canvas x y spaces_info } {
> > > > > > > .... ;# get the info from $spaces_info and write it to
> > > > > > > $canvas at $x $y
> > > > > > > }
> > > > > > >
> > > > > > > proc clickOnSpacesButton { email } {
> > > > > > > if { [config::getKey ccard_in_cl] } {
> > > > > > > ::abook::setPersistantData $email show_ccard 1 ;# actually
> > > > > > > invert the old value
> > > > > > > } else {
> > > > > > > openCCard $email
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > proc openCCard { email } {
> > > > > > > toplevel .ccard
> > > > > > > ..........
> > > > > > > canvas $cvs ...
> > > > > > > .....
> > > > > > > buildSpaceInfo $cvs $x $y [GetSpacesInfo $email]
> > > > > > > }
> > > > > > >
> > > > > > > proc drawContact { email } {
> > > > > > > ...
> > > > > > > if { [abook::getPersistantData $email show_cccard 0] == 1 } {
> > > > > > > buildSpaceInfo $pgBuddy.cl [expr $contact_x + 10] [expr
> > > > > > > $contact_y + 30] [GetSpacesInfo $email]
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > that would be it.. we only need to write the code handling that
> > > > > > > data once. And we could add the option in the
> > > > > > > appeearance tab of the preferences.
> > > > > > > What do you think ?
> > > > > > > Because I am SURE that people will complain about the ccard not
> > > > > > > being there.
> > > > > > > + your ccard plugin is so nice, I would really hate to waste it :)
> > > > > > > but for those who like usability, they can use your method.
> > > > > > >
> > > > > > > also, I would say that the first time you click on the spaces
> > > > > > > button, a window would popup asking you which
> > > > > > > method you choose, and in order to make it nice, a window like
> > > > > > > this :
> > > > > > > -------------------------------------------------------------------------
> > > > > > > | How do you want to see your contact's spaces information
> > > > > > > |
> > > > > > > |
> > > > > > > |
> > > > > > > | o In a contact card o Embeded in the contact
> > > > > > > list |
> > > > > > > |
> > > > > > > |
> > > > > > > | ----------------------------
> > > > > > > ------------------------------ |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | | Screenshot | | Screenshot
> > > > > > > | |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | | | |
> > > > > > > | |
> > > > > > > | -----------------------------
> > > > > > > ------------------------------- |
> > > > > > > |
> > > > > > > |
> > > > > > > | [Ok] [Cancel]
> > > > > > > |
> > > > > > > |
> > > > > > > |
> > > > > > > -------------------------------------------------------------------------
> > > > > > >
> > > > > > >
> > > > > > Well, this makes it again a bad experience for someone using amsn
> > > > > > for
> > > > > > the first time. It's ok we ask for the tab-closing when closing
> > > > > > chatwins or if he wants to close the app when he closes the main
> > > > > > window ... as he might care enough of not loosing data (chats when
> > > > > > not saving logs). But this is just an interface preference... If I
> > > > > > had to use an aplication for the first timle and ever y time I click
> > > > > > something it asks me a question I wouldn't use it for long ...
> > > > > >
> > > > >
> > > > > I don't really see how it could be a bad user experience, it's a one
> > > > > time choice, there is no reason why it
> > > > > would bother a user, especially if he's going to use amsn for a
> > > > > while, and for such a great feature, I really
> > > > > don't think it would bother someone (first time you use mouse
> > > > > gestures with opera, it asks you if you want to
> > > > > enable them, or disable them, or whatever, and it's fine to ask such
> > > > > a question). Also, by doing such a popup,
> > > > > users will know that they have two ways of showing the ccard, either
> > > > > inline or not and it's important especially
> > > > > if you don't want the feature to go to waste since not everyone
> > > > > checks the preferences.
> > > > >
> > > > > > So, what I had in mind ... we just draw it inline, but there's a
> > > > > > config var to prohibit this. Whoever likes could make a contactcard
> > > > > > plugin, reusing some code of aMSN (the drawing of photos etc, cfr
> > > > > > infra), setting the var to 0 and so when a user clicks the button, a
> > > > > > ccard is created. We could even ship such a plugin by default,
> > > > > > though
> > > > > > I'd like it to be disabled by default :).
> > > > > >
> > > > >
> > > > > Well, I think that that's what YOU had in mind, and it's not what I
> > > > > have in mind, so why would it be done your
> > > > > way and not my way. I'm not saying your way is not good, I'm just
> > > > > saying that over time, I realize that you
> > > > > really rarely do compromises. I say we make a poll to avoid any
> > > > > problems/tensions. Your idea of inline, I just
> > > > > hate it, I really don't think it would go there (but I tried with
> > > > > latest SVN and it does look nice), and I
> > > > > really think that a ccard like WLM's would be the best way to go.
> > > > > Your thing about setting the var to 0 and having a separate plugin is
> > > > > just stupid IMHO because it complicates
> > > > > things so much. An option would be so much better, no need for a
> > > > > separate plugin or whatever, we already put
> > > > > that in core, why do you want your idea in the core and my idea only
> > > > > as a plugin???
> > > > >
> > > > > > > ok, that's a long enough mail for now, and I think (hope) you get
> > > > > > > my point.
> > > > > > > Now, what do you guys think ?
> > > > > > > we need to decide on this so we can move forward!
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > p.s: I think a modular function that writes the ccard info like
> > > > > > > shown above can already be written until we
> > > > > > > decide what to choose
> > > > > >
> > > > > > I'm now doing it in the guicontactlist.tcl code, but once it's done
> > > > > > it
> > > > > > could be moved to iot's own proc with parameter $canvaswidget and
> > > > > > $xpos $ypos. But for now, I'm just doing it inside
> > > > > > guicontactlist.tcl..
> > > > > >
> > > > >
> > > > > I don't get it. I saw your code being inside the drawContact proc and
> > > > > it frustrated me, seriously, what are you
> > > > > loosing in putting it in a separate proc from the start? it's so much
> > > > > more complicated and bug-prone to
> > > > > refactor the code afterwards while it would have taken you only 5
> > > > > seconds to create a proc for it. I don't see
> > > > > why you're being hard-headed on this matter, u got nothing to loose
> > > > > to do it like I said, even if we were going
> > > > > to keep the inline thing as default and no popup window asking to
> > > > > choose between the two methods, then you still
> > > > > have nothing to loose to do it like I said...
> > > > >
> > > > > Anyways, apart from that, good job so far, it looks nice!
> > > > >
> > > > > > Karel.
> > > > > >
> > > > > > > KKRT
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Jan 13, 2007 at 02:41:10PM +0100, Karel Demeyer wrote:
> > > > > > > > Forgot (for my proposal): as it takes some time to fetch all
> > > > > > > > needed
> > > > > > > > data, on a click, drawContact should only draw a temporary
> > > > > > > > message
> > > > > > > > like "Please stand by ..." and call the fetching procs ... then
> > > > > > > > after
> > > > > > > > this, the fetching procs should send an event or call
> > > > > > > > drawContact
> > > > > > > > again to draw the data...
> > > > > > > >
> > > > > > > > 2007/1/13, Karel Demeyer <[EMAIL PROTECTED]>:
> > > > > > > > > If (and it still has to be chosen, I'm not pushing anything
> > > > > > > > > (well, not
> > > > > > > > > too hard :p)) the choice would be made for inline ccard in
> > > > > > > > > CL, this
> > > > > > > > > has to be done:
> > > > > > > > >
> > > > > > > > > * Add an abook var (boolean), not volatile so it 's still
> > > > > > > > > there in
> > > > > > > > > another session, like "CcardShown" for every user. If this
> > > > > > > > > is not
> > > > > > > > > volatile, we have an extra feature over WLM, to keep some
> > > > > > > > > user's ccard
> > > > > > > > > data allways shown, I would like this.
> > > > > > > > >
> > > > > > > > > * In guicontactlist.tcl:
> > > > > > > > > - in proc drawContact, have a check for this var and
> > > > > > > > > if
> > > > > > > > > available, draw the data underneah the contact, according to
> > > > > > > > > my mockup
> > > > > > > > > :)
> > > > > > > > > - in that same proc, rearrange the tags somewhat.
> > > > > > > > > the tag all
> > > > > > > > > things of the contact have should be added to every item of
> > > > > > > > > the space,
> > > > > > > > > also the stars (it is this way now), for the dragging procs.;
> > > > > > > > > a new
> > > > > > > > > tag should be created and changed in the bindings for
> > > > > > > > > clicking on
> > > > > > > > > those items (all nickname items, statusicon, psm items,
> > > > > > > > > statusmsg) to
> > > > > > > > > open a chatwindow;
> > > > > > > > > - have a binding on the star that: *toggles the abook
> > > > > > > > > var;
> > > > > > > > > *calls the drawContact proc for that specific contact; *call
> > > > > > > > > the
> > > > > > > > > rearrangeList (or what it's named) proc to move everything
> > > > > > > > >
> > > > > > > > > It's not too much work in fact thus. I guess it's less work
> > > > > > > > > than
> > > > > > > > > changing the ccard plugin. An eventual ccard plugin should
> > > > > > > > > made
> > > > > > > > > possible to prevent drawContact from drawing the spaces info
> > > > > > > > > (a global
> > > > > > > > > ::config key "drawSpacesOnCL" maybe) and change the binding
> > > > > > > > > of teh
> > > > > > > > > "star" icon.
> > > > > > > > > Anyway, I don't have the time to do this. In fact I have a
> > > > > > > > > very hard
> > > > > > > > > exam of one of my Law courses monday so I shouldn't even be
> > > > > > > > > mailing
> > > > > > > > > this but I couldn't resist as I want to lobby for my idea :)
> > > > > > > > >
> > > > > > > > > Karel.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2007/1/13, Karel Demeyer <[EMAIL PROTECTED]>:
> > > > > > > > > > I favour to have this data in the CL as all those new
> > > > > > > > > > windows only
> > > > > > > > > > cover up your screen. Added that when we don't want window
> > > > > > > > > > borders
> > > > > > > > > > drawn by the windowmanager (and I guess we don't), it means
> > > > > > > > > > we'll have
> > > > > > > > > > windows unmanaged by the windowmanager and thus allways on
> > > > > > > > > > top on teh
> > > > > > > > > > screen. I, for one, find this very unpleasant. Addded
> > > > > > > > > > that those
> > > > > > > > > > windows are not consistent with all other UI apsects on
> > > > > > > > > > one's
> > > > > > > > > > computer, I think it's bad UI design.
> > > > > > > > > >
> > > > > > > > > > See, when you want to do a task on your PC, you want the
> > > > > > > > > > UI to enable
> > > > > > > > > > you to work fast and efficient. If I open this data by
> > > > > > > > > > clicking on
> > > > > > > > > > that "star" and the data appears just underneath my
> > > > > > > > > > pointer, it's very
> > > > > > > > > > fast to reach with the mouse. If I click, and it opens
> > > > > > > > > > another
> > > > > > > > > > window, I have to rescan my screen to find out where to
> > > > > > > > > > find it's info
> > > > > > > > > > as it will not be just where I was. Ok, I guess WLM's
> > > > > > > > > > ccards appear
> > > > > > > > > > close to the place you clicked... but if they appear under
> > > > > > > > > > your
> > > > > > > > > > cursor, it means they cover the data of the CL. If they
> > > > > > > > > > appear next
> > > > > > > > > > to the contactlist, they appear further from your pointer
> > > > > > > > > > and so you
> > > > > > > > > > have to move your mouse for longer, which is not a good
> > > > > > > > > > thing.
> > > > > > > > > > Also, when you scan your CL to find a contact, you go
> > > > > > > > > > top-down or
> > > > > > > > > > bottom-up. As in most languages we read top-down, most ppl
> > > > > > > > > > will scan
> > > > > > > > > > there CL top-down (sidenote: this is another reasong why I
> > > > > > > > > > dislike
> > > > > > > > > > WIndow's start-menu bottom-left). So, if I'm scanning my
> > > > > > > > > > list, find
> > > > > > > > > > my friend, click the star, the fastest place to reach for
> > > > > > > > > > the new info
> > > > > > > > > > is just underneath it as I was already moving my eyes in
> > > > > > > > > > that
> > > > > > > > > > direction... Those seem like small details maybe but in
> > > > > > > > > > fact it
> > > > > > > > > > makes life easier for a lot of people. I guess if we
> > > > > > > > > > implement it
> > > > > > > > > > this way there will be complaints, just as there are
> > > > > > > > > > complaints about
> > > > > > > > > > ever UI design choice (yeah, even if they come from Apple
> > > > > > > > > > Inc. ;)) But
> > > > > > > > > > I think it's worth the hassle.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Karel
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2007/1/13, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 13/01/07, NoWhereMan <[EMAIL PROTECTED]> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Karel Demeyer" <[EMAIL PROTECTED]>
> > > > > > > > > > > > To: "Mailing list for developers and everyone helping
> > > > > > > > > > > > AMSN"
> > > > > > > > > > > > <amsn-devel@lists.sourceforge.net>
> > > > > > > > > > > > Sent: Saturday, January 13, 2007 11:57 AM
> > > > > > > > > > > > Subject: Re: [Amsn-devel] Contact Cards and MSN spaces
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >I just implemented an Event for a changed space. Now,
> > > > > > > > > > > > >I was asking
> > > > > > > > > > > > > myself ... how do we know when we can unset the
> > > > > > > > > > > > > star's appearance ?
> > > > > > > > > > > > > When do we know the blog is read ? When our user
> > > > > > > > > > > > > clicks the star ?
> > > > > > > > > > > > > Doesn't the protocol let us know when the blog has no
> > > > > > > > > > > > > unread items or
> > > > > > > > > > > > > unseen photos ?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Karel.
> > > > > > > > > > > >
> > > > > > > > > > > > in MSN7.5 gleam disappears when you click to see the
> > > > > > > > > > > > ccard, so I guess
> > > > > > > > > > > that
> > > > > > > > > > > > once you clicked you can set a local variable
> > > > > > > > > > > > read($user) to 1;
> > > > > > > > > > > > gleams are client-side, so if you set a space to read
> > > > > > > > > > > > on a client if you
> > > > > > > > > > > log
> > > > > > > > > > > > in from another pc you should still see blinking gleams.
> > > > > > > > > > > >
> > > > > > > > > > > > about the ccard embedded in CL... I don't know, it
> > > > > > > > > > > > would be too
> > > > > > > > > > > > "compressed"... how about an in-CL ccard ?
> > > > > > > > > > > > http://i18.tinypic.com/2e5mg02.png
> > > > > > > > > > > >
> > > > > > > > > > > > with a "< back" link to the main cl... I don't know
> > > > > > > > > > > > maybe it's even worse
> > > > > > > > > > > > than the msn-style ccards :P
> > > > > > > > > > >
> > > > > > > > > > > I prefer karel's method :P I don't mind the popup card to
> > > > > > > > > > > be honest, but I
> > > > > > > > > > > do think Karel's 'expand-the-contact' thing has a certain
> > > > > > > > > > > appeal :) I like
> > > > > > > > > > > it and if we're saying no to the popup card I think we
> > > > > > > > > > > should be saying yes
> > > > > > > > > > > to the in-Cl expand thing :P
> > > > > > > > > > >
> > > > > > > > > > > > bye
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > -------------------------------------------------------------------------
> > > > > > > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > > > > > > Join SourceForge.net's Techsay panel and you'll get the
> > > > > > > > > > > > chance to share
> > > > > > > > > > > your
> > > > > > > > > > > > opinions on IT & business topics through brief surveys
> > > > > > > > > > > > - and earn cash
> > > > > > > > > > > >
> > > > > > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Amsn-devel mailing list
> > > > > > > > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > -------------------------------------------------------------------------
> > > > > > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > > > > > Join SourceForge.net's Techsay panel and you'll get the
> > > > > > > > > > > chance to share your
> > > > > > > > > > > opinions on IT & business topics through brief surveys -
> > > > > > > > > > > and earn cash
> > > > > > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > > > > >
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Amsn-devel mailing list
> > > > > > > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------------------------
> > > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > > Join SourceForge.net's Techsay panel and you'll get the chance
> > > > > > > > to share your
> > > > > > > > opinions on IT & business topics through brief surveys - and
> > > > > > > > earn cash
> > > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > > _______________________________________________
> > > > > > > > Amsn-devel mailing list
> > > > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > > >
> > > > > > > -------------------------------------------------------------------------
> > > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > > > > > share your
> > > > > > > opinions on IT & business topics through brief surveys - and earn
> > > > > > > cash
> > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > > _______________________________________________
> > > > > > > Amsn-devel mailing list
> > > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > > > >
> > > > > >
> > > > > > -------------------------------------------------------------------------
> > > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > > > > share your
> > > > > > opinions on IT & business topics through brief surveys - and earn
> > > > > > cash
> > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > > _______________________________________________
> > > > > > Amsn-devel mailing list
> > > > > > Amsn-devel@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > >
> > > > > -------------------------------------------------------------------------
> > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > > > share your
> > > > > opinions on IT & business topics through brief surveys - and earn cash
> > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > _______________________________________________
> > > > > Amsn-devel mailing list
> > > > > Amsn-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > > > >
> > > >
> > > > -------------------------------------------------------------------------
> > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > > > your
> > > > opinions on IT & business topics through brief surveys - and earn cash
> > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > _______________________________________________
> > > > Amsn-devel mailing list
> > > > Amsn-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > >
> > > -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > > your
> > > opinions on IT & business topics through brief surveys - and earn cash
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Amsn-devel mailing list
> > > Amsn-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/amsn-devel
> > >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Amsn-devel mailing list
> > Amsn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
