headers
Ingo Klöcker | 1 Dec 2003 01:42
Picon
Favicon

Re: [PATCH] Replacing email selection dialog in kmail

On Monday 01 December 2003 00:34, Aaron J. Seigo wrote:
> On Sunday 30 November 2003 12:02, Ingo Klöcker wrote:
> > Or why it's not possible to add a distribution list to the
> > list of addressees (and by this I mean the name of the distribution
> > list and not all it's members).
>
> this is indeed a bug, but has nothing to do with the layout of the
> dialog.
>
> > Why can one Add, Edit or Remove
> > contacts from the addressbook in an address _selection_ dialog? Why
> > can one save distribution lists from there?
>
> two words: use case.

I can come up with use cases for everything. The question is whether 
those use cases occur often enough to rectify adding a button for this.

> UC 1: user opens up address picker, adds a few addresses, which to
> add another address.

??? This sentense doesn't make sense, does it? Anyway, I guess I know 
what you want to say. But normally the user will hopefully right click 
on all new addresses (in the message viewer) and add them this way. Why 
should a user enter an address by hand? This will just lead to UC 2. ;-)

> UC 2: user opens up address picker, notices than an email addy is
> wrong and should be changed.

Then why is the email address not editable directly in the listview? This
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ingo Klöcker | 1 Dec 2003 01:48
Picon
Favicon

Re: [PATCH] Replacing email selection dialog in kmail

On Monday 01 December 2003 00:39, Aaron J. Seigo wrote:
> On Sunday 30 November 2003 03:26, Tobias Koenig wrote:
> > The splitter has gone
>
> and it works properly when resizing, etc? i'm recompiling
> kdelibs/base atm so can't check myself... the proportions should
> remain, with the center column not growing... sorry for not being
> able to try it out right now myself

Yes, it does work properly when resizing. I don't know what you mean 
with "etc", so I can't comment on "etc".

> > as well as the New, Edit and Remove buttons. Instead an 'Address
> > Book...' button is added which allows you to start kaddressbook.
>
> see my email in reply to Ingo why this is a poor idea, IMHO.

Unless someone else actually properly implements the functionality 
behind those buttons (see my other message) you should accept this as 
an interim solution.

> > Furthermore you can move distribution to the 'Selected
> > Addresses' listbox now.
>
> whee! yes, putting them in a group is good. the only thing i'd change
> there is hiding that item when there are no distribution lists. a
> quick check for (distLists.begin() == distLists.end()) should work
> ...

Also the members of the distribution lists should still be listed below
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dawit A. | 1 Dec 2003 01:53
Picon
Favicon

Re: PATCH: Better cross-domain cookie detection [BR 66090]

On Sunday 30 November 2003 15:11, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun November 30 2003 17:51, Dawit A. wrote:
> > Okay, patch is attached. It seems to work fine now.
>
> Starts to look good. There are two changes in there that might be
> problematic though:
>
> - -            KURL r = req->m_docLoader->doc()->URL();
> - -            job->addMetaData("referrer", r.url());
> has effectively become:
>              KHTMLPart *part = req->m_docLoader->part();
> +            job->addMetaData( "referrer", part->url().url() );
> +            job->addMetaData( "cross-domain", part->sourceURL().url() );
>
> This replaces  req->m_docLoader->doc()->URL() with
> req->m_docLoader->part()->url(), I'm not sure if that is a good idea.

I have reverted it back with the exception that we no longer need to assign it 
to a KURL object first.

> And more general, it fails to check if req->m_docLoader->part() is null.

Added the check for a NULL part. I assumed it could never happen, but it never 
hurts to check anyways. 

--

-- 
Regards,
(Continue reading)

Permalink | Reply | 9 comments |
headers
Zack Rusin | 1 Dec 2003 02:15
Picon
Favicon

Re: [PATCH] Replacing email selection dialog in kmail

On Sunday 30 November 2003 19:48, Ingo Klöcker wrote:
> On Monday 01 December 2003 00:39, Aaron J. Seigo wrote:
> > On Sunday 30 November 2003 03:26, Tobias Koenig wrote:
> > > The splitter has gone
> >
> > and it works properly when resizing, etc? i'm recompiling
> > kdelibs/base atm so can't check myself... the proportions should
> > remain, with the center column not growing... sorry for not being
> > able to try it out right now myself
>
> Yes, it does work properly when resizing. I don't know what you mean
> with "etc", so I can't comment on "etc".

I don't exactly remember who requested them, but the reasoning iirc was 
"sometimes i want to see full names and emails in one tree, and because 
both of them scale by the same amount i'm often left with a huge window 
with one completely unused tree and other barely fitting the 
informations i wanted", hence the splitters.

> > > as well as the New, Edit and Remove buttons. Instead an 'Address
> > > Book...' button is added which allows you to start kaddressbook.
> >
> > see my email in reply to Ingo why this is a poor idea, IMHO.
>
> Unless someone else actually properly implements the functionality
> behind those buttons (see my other message) you should accept this as
> an interim solution.

Well, "this is rather crappy" is obviously my comment and it's there 
because _this_ was the interim solution. Tobias was supposed to export
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benoit Walter | 1 Dec 2003 02:19
Picon
Favicon

Re: Review of background dialog.

> A review of the background settings dialog reviewed the following issues:

> 1) Meaning of "Blending" options is unclear.
It has been already discussed, but as very few people understand it and fewer 
people use it, my opinion is that it should be in the advanced dialog. OTOH, 
if we move it there, another preview monitor is needed in the advanced 
dialog... And removing feature is not always a solution... but who needs 
Blending? A deadlock.

> 2) "Position" refers to the position of the picture but this is not clear.
Using buttons which clearly shows the position of the image in the screen 
would be a big improvement for usability. Mockups (or prototype) are needed.

> 3) The comobox behind "Colors" lists a variety of gradients and patterns
> including two empty entries.
Are you sure? No empty entry in my recent version.

> 4) The option for the background icon text color is hidden under Advanced
> where it is very hard to find.
It is related to backround, perhaps. But I think it would be much better to 
have this option in the Icons tab of the "Desktop Behaviour" dialog. I think 
it makes more sense, for example the tab is only enabled when icons on 
desktop are enabled. In the background dialog, it is hidden when icons on 
desktop are disabled, which makes it more difficult to find the option in 
case you re-enable icons on desktop...

> 5) The title "Options" of the groupbox is meaningless.
Perhaps "Settings" :-) It is actually a good example of a frame that is only 
there for esthetical purposes, but the reason why elements are grouped 
together is hard to explain . Without frame, if would not look good...
(Continue reading)

Permalink | Reply | 3 comments |
headers
Aaron J. Seigo | 1 Dec 2003 03:39
Picon
Favicon
Gravatar

Re: [PATCH] Replacing email selection dialog in kmail


On Sunday 30 November 2003 05:42, Ingo Klöcker wrote:
> On Monday 01 December 2003 00:34, Aaron J. Seigo wrote:
> > On Sunday 30 November 2003 12:02, Ingo Klöcker wrote:

> I can come up with use cases for everything. The question is whether
> those use cases occur often enough to rectify adding a button for this.

IME, yes.. these are real uses; conversely, you have yet to show that these 
useful buttons hinder the use of the dialog. all i've seen in this thread are 
assertions to that effect, but not one bit of explanatory reasoning or 
evidence.

> > UC 1: user opens up address picker, adds a few addresses, which to
> > add another address.
>
> ??? This sentense doesn't make sense, does it? 

sorry.. typo.. s/which/wishes/

> Anyway, I guess I know 
> what you want to say. But normally the user will hopefully right click
> on all new addresses (in the message viewer) and add them this way. Why
> should a user enter an address by hand?

you're right, in fact in a perfect world all the addresses they need would 
come pre-loaded in the address book. we don't live in that perfect world. in 
the real world people DO need to enter addresses by hand. i do it all the 
time when on the phone with people, for instance. and i've usually got an 
email composer window open already...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stanislav Karchebny | 1 Dec 2003 07:39
Picon

[patch] trivial kwin geometrytip fix

* Fix incorrect sprintf() parameters (+%d vs %+d)
* Make it display as
                        +256,+256
                       (1020 x 653)
instead of
                            +256,
                   +256 (1020 x 653)

Index: geometrytip.cpp
===================================================================
RCS file: /home/kde/kdebase/kwin/geometrytip.cpp,v
retrieving revision 1.9
diff -u -p -r1.9 geometrytip.cpp
--- geometrytip.cpp     11 Nov 2003 18:38:19 -0000      1.9
+++ geometrytip.cpp     30 Nov 2003 11:44:12 -0000
 <at>  <at>  -68,7 +68,7  <at>  <at>  void GeometryTip::setGeometry( const QRe

     h = QMAX( h, 0 ); // in case of isShade() and PBaseSize
     QString pos;
-    pos.sprintf( "%+d,%+d&nbsp;(<b>%d&nbsp;x&nbsp;%d</b>)",
+    pos.sprintf( "+%d,+%d<br>(<b>%d&nbsp;x&nbsp;%d</b>)",
                      geom.x(), geom.y(), w, h );
     setText( pos );
     adjustSize();

--

-- 
keep in touch. berkus. -- http://lye.upnet.ru/
Permalink | Reply | 1 comment |
headers
Andras Mantia | 1 Dec 2003 09:54
Picon
Favicon

Re: [PATCH] Fixing the KMix applet


Indeed, this is match cleaner and simpler. I told you, I'm a simple user. :-)

Another bug: the applet is unusable if it's put on a vertical panel.

Andras

> I get the idea. Thanks for the hint. But I applied a slightly different
> patch (only like this I can be sure to break nothing):
>
> diff -u -r1.64 mixdevicewidget.cpp
> --- mixdevicewidget.cpp 24 Nov 2003 22:44:48 -0000      1.64
> +++ mixdevicewidget.cpp 30 Nov 2003 21:22:26 -0000
>  <at>  <at>  -258,7 +258,8  <at>  <at> 
>         // create record source LED
>         if( m_mixdevice->isRecordable() && ! isSwitch() )
>         {
> -               layout->addSpacing( 2 );
> +               if ( showRecordLED )
> +                 layout->addSpacing( 2 );
>                 m_recordLED = new KLedButton( Qt::red,
>                                
> m_mixdevice->isRecSource()?KLed::On:KLed::Off, KLed::Sunken,
> KLed::Circular, this, "RecordLED" );
>
> > And another bug: changing the direction of the sliders breaks the
> > layout...
>
> And changing the colors resizes the applet to the width of one slider or
> resets the applet to say "Invalid mixer".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tobias Koenig | 1 Dec 2003 11:13
Picon
Favicon

Re: [PATCH] Replacing email selection dialog in kmail

On Sun, Nov 30, 2003 at 08:15:01PM -0500, Zack Rusin wrote:
> On Sunday 30 November 2003 19:48, Ingo Klöcker wrote:
Hi,

> > Yes, it does work properly when resizing. I don't know what you mean
> > with "etc", so I can't comment on "etc".
> 
> I don't exactly remember who requested them, but the reasoning iirc was 
> "sometimes i want to see full names and emails in one tree, and because 
> both of them scale by the same amount i'm often left with a huge window 
> with one completely unused tree and other barely fitting the 
> informations i wanted", hence the splitters.
Hmm, wouldn't a QGridLayout::setColStretch(0,10) be enough for this
purpose?

> > Unless someone else actually properly implements the functionality
> > behind those buttons (see my other message) you should accept this as
> > an interim solution.
> 
> Well, "this is rather crappy" is obviously my comment and it's there 
> because _this_ was the interim solution. Tobias was supposed to export 
> the addressee editing widget from kaddressbook, but i guess didn't have 
> enough time to do it.
It was not the lack of time but the structural changes that would have
been needed to factor out the dialog of KAddressBook. We were short
before feature freeze, so we (Cornelius and me) agreed to postpone it to
after 3.2.

> > Also the members of the distribution lists should still be listed
> > below the distribution list names to make it easy for the user to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Koenig | 1 Dec 2003 11:15
Picon
Favicon

Re: [PATCH] Replacing email selection dialog in kmail

On Mon, Dec 01, 2003 at 01:48:02AM +0100, Ingo Klöcker wrote:
> On Monday 01 December 2003 00:39, Aaron J. Seigo wrote:
Hi,

> > > Furthermore you can move distribution to the 'Selected
> > > Addresses' listbox now.
> >
> > whee! yes, putting them in a group is good. the only thing i'd change
> > there is hiding that item when there are no distribution lists. a
> > quick check for (distLists.begin() == distLists.end()) should work
> > ...
Yepp, possible

> Also the members of the distribution lists should still be listed below 
> the distribution list names to make it easy for the user to check who's 
> in the list.
Hmm, but shall they be selectable as well?

Ciao,
Tobias
--

-- 
Can a government that shoots at reporters be democratic?
Separate politics from religion and economy!
Permalink | Reply | 2 comments |

Gmane