[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] Re: kdenetwork/kopete/protocols/oscar/icq/ui
From:       Casey Allen Shobe <cshobe () osss ! net>
Date:       2004-07-11 23:56:05
Message-ID: 200407111656.05431.cshobe () osss ! net
[Download RAW message or body]

On Sunday 11 July 2004 15:33, Stefan Gehn wrote:
> qlabel does not allow copynpaste, readonly (not disabled) allows that and
> is surely helpful for address fields and the like.

Well, it was just one example...  A disabled multiline area could do the same.

> That happens before showing the dialog and it's quite fast. If you don't
> know it, KDE once had no designer so all dialogs were created manually at
> runtime (actually they are still because all uic does is create code). It's
> not as slow as you think it might be.

I know, but you have all the UI-generated code PLUS your code, so it's still 
more.

> But they contain the same information, the only difference is if it's your
> info or info from somebody else.

And how it's displayed, and even laid out.

> I can't think of a reason why users would ever complain about that. They
> don't waste space either.

I'm a user, and I complain.  But you told me to look at the styleguide.  Any 
styleguide worth it's salt will tell you that an underlined character means 
alt+that letter will make the cursor go there - it's pretty standard across 
many user interfaces and operating systems.  Not that KDE has to be like any 
other system, but that's the convention KDE happens to follow.

> nothing speaks against having this inside code instead of inside the ui.

Maintainability factor.

> Your changes were about the fourth redo, that speaks for itself.

They would have been actually do-able correctly had there been two layouts.  
But you mash in two widgets where one is supposed to go, and it makes that 
part of the dialog wider than it will be once one or the other is removed, 
and then complain when it formats wrong in one case or the other?

> So this ui came from /dev/null and was just there?

There's nothing wrong with the edit account dialog UI.  And I've already said 
that the user info UI should not have been committed.

> What XML file? designer files are not natively used in case you mean that.

I know that, but in the source distribution - the size would hardly be any 
different.

> I have all the layouting, spacing and stretching inside the .ui and just
> edit some things, that's way easier than doing everything by hand or
> editing two .uis and read/fill them with data.

> see above, they contain the same information, just for different users,
> that's why they should look the same, even if one of them is not editable.

Sorry but I simply don't agree with either of those statements, and doubt I 
can argue you into seeing my point of view.  Anyways the discussion of 
whether to split userinfo dialogs into two or not is a question for another 
day and concerns more protocols than just AIM, so I think it's best to let it 
rest for now, and I won't mess with them until I know how we're going to 
proceed (plenty else to do).

> But cramming in changes without discussing things first is no valid point
> to commit right away (I also missed KDE freezes a couple of times, it's
> just how life goes). For fixing bugs keeping users from using the whole app
> this might be true but in this case I don't think so.

It's been discussed, with Grzegorz and Till to the greatest extent, secondly 
with Olivier, and thirdly with Matt.  I've talked about it nearly constantly 
on IRC, asking many questions and mentioning my ideas, there's been a good 
amount of discussion with users and other developers too, plus the kde-cvs 
log clearly indicates what I've been working on.  Grzegorz and I 
misunderstood each other and I committed before he wanted to, but we've 
discussed and worked out the kinks in a fairly civil manner, which you did 
not give me the liberty of.  Besides, what he wanted me to ask him about 
before committing was potentially buggy C++ coding, not just simple UI work.  
I did no such work on ICQ, and if I had, I would have discussed it in much 
greater detail first.

> Me not going to work on new things does not mean that oscar is
> unmaintained. There's still Matt, Will and Marcello (sorry in case I got
> that name wrong) working on oscar. I'm sure you could have mailed one of
> them some links to previews.

Matt and Will both were aware of my work, and I made a point of showing Matt 
the identical dialogs implemented in Gadu.

> (and I'm not talking about fixing strings or something, I'm talking about
> huge changes like this one).

Sorry what?  How is this a "huge change"?  People are laughing at us for 
arguing over something so small.

> If the Kopete team agreed with this one then I wouldn't have reverted it

That depends on what you define the Kopete team as being.  I consider it to be 
more than 2-3 people.

> We all agreed with you on the first one back then, that's why it's in
> Kopete. 

No, you reverted my changes then as you did now, reacting explosively, instead 
of just discussing things in a kind manner.  Like I told you in E-mail then, 
just let me know if you don't like something I do.  I'm more than happy to 
revert it myself or work with you to make it suitable for both of us, but to 
react like this is just instigating a huge fight, which is not necessary (and 
I don't know why you think it is).

> Why do you have to make it worse now? I don't have a clue why things like
> this have to change every other week. If it would have been bad then we
> wouldn't have shipped it. 

It was _better_.  It was not perfect.  There were limitations I faced because 
at the time I did not touch a single line of C++ code.  Plus after using my 
own designs for months on end, and talking to a lot of users who were all 
using the same dialogs, I realized subtle things that could be better.  These 
are very minor changes, nothing like the originals, which were very 
different, and required coders from all the protocols to agree to coding 
support for.

> The rest of the dialog is less important? Why does this text need more
> attention?

Why did you approve of it half a year ago if you are against it now?  To me, 
it made sense then because it was generic instructions outside of a groupbox.  
Now it's been geared to registration (which is what it really was in the 
first place), so it's in a more fitting place.  I left it as italics because 
that was one less thing to change and annoy people like you with.  It so 
happens that the groupbox also makes the bold text (which I added in the 
design prior to the groupbox) completely unecessary, since the text labels 
the registration button or link.  So I'll be happy to eliminate the bold and 
italics...they aren't necessary.

But that's scarcely a reason to just revert and blow up at someone.

> Nope, ask somebody doing DTP, using more than one style at the same time is
> not a good idea.

Bold italic is very common.  In many font choosing settings, including those 
in KDE, you have specific choice between plain, bold, italic, and bold 
italic.  If I had used regular text or plain bold in that qlabel in addition 
to the other two, it would be a different story.  Anyways plaintext is fine.

As for the link, it's where it is because I want to replace it with a button 
for aesthetics reasons (see the Gadu edit account dialog), but that's 
something I don't know how to do yet.

> Are you paranoid?

No, but you're flaming, though it seems to be cooling down a bit now.

> So they leave them alone and that's it. I don't have to think about paths
> for executable either when they are in a prefs-dialog, still these settings
> are not hidden (because it's simply unneeded because people not needing it
> will ignore it).

Yes, you can learn to ignore it, but when you look at a dialog with 3 
checkboxes, it's less intimidating than looking at a dialog with 2 
checkboxes, an lineedit, a spinbox, a button, and one additional piece of 
text.  Less intimidation == better.

> it's actually the same, one click.

Yes, precisely, the one click, but less hunting around for it (since you 
already had to click it to change the defaults), more pleasing to the eye (a 
less cluttered-looking layout, and not so confusing).

> And somehow I don't believe in this "other users" story anyway (I have
> never heard that on IRC nor did anybody else come up with it, sounds pretty
> weird, huh?) :)

I can start logging, and showing you specific examples.  But rather, I'll just 
leave it to list members to post their opinions in reply to the screenshots.

> Anyway, do what you think is right but please communicate with the rest
> instead of just comitting right away.

Why?  The maintainers were all aware of what I was doing, the changes were 
small and easily reversible, and one of the main purposes of CVS is to have 
the ability to look at how something was before.  Even with pending freezes, 
we're not releasing tomorrow.  I'm more than willing to change anything back 
that popular opinion is against, or even that a couple people don't like and 
I have no reason to disagree with (i.e. the typeface).  But these things can 
be done without a full revert, and more importantly without a huge reaction 
and fight like this.

Just come find me on IRC and communicate with the same attitude you did 
earlier today, or send me an E-mail.  Instead of treating me like an idiotic 
moron who knows nothing who should be your slave, treat me like an equal 
who's opinion you differ with.  You wanted teamwork, then be willing to work 
for it.  I'm much more likely to do what you want if you talk it over with me 
and explain why it's important to you in a civil manner, instead of blowing 
up like this.

-- 
  Casey Allen Shobe  |  http://casey.allen.shobe.info
    cshobe@osss.net  |  ICQ: 1494523  |  AIM: SomeLinuxGuy
      Open Source Software Solutions  |  http://osss.net
_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]