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

List:       kde-core-devel
Subject:    Re: PATCH: Re: kdelibs/kdeui
From:       Ellis Whitehead <kde () ellisw ! net>
Date:       2002-01-30 3:48:35
[Download RAW message or body]

> It doesn't matter how long or how short the diff is. a perfectly looking
> one-liner might deeply screw up everything already. 

My concern is that I don't want to post patches for a bunch of unrelated 
mini-commits -- it would seem an awful lot like list noise.  Especially since 
I've already been posting enough little questions and bug reports in the last 
couple weeks to get annoyed at seeing my own name. ;)  Besides, how many 
PATCHes have to be posted before people stop looking at them?  And on the 
other hand, gathering enough mini-paches together to make a more reasonable 
posting would mean letting patches accumulate and then committing more at one 
time than I would like.

> while reading your commit
> log I remembered we had that already, and we had problems with it. cvs log
> and annotate should give you insights.

Are you thinking of this?:
revision 1.176
date: 2001/03/15 19:34:57;  author: faure;  state: Exp;  lines: +2 -0
Unplug from main kaccel in destructor - fixes dirk's crash.

What's annotate?

I've attached my next patch as another example of something that I think just 
adds noise to the list.  Please let me know if you would want this sort of 
thing to be posted.

Regards,
Ellis

On Tuesday 29 January 2002 21:43, Dirk Mueller wrote:
> On Die, 29 Jan 2002, Ellis Whitehead wrote:
> > With individual commits, though, it does bring up the question of just
> > how insignificant does a patch need to be to forego the "post-it first"
> > rule?
>
> The point is while one might consider the change insignificant, for
> somebody else it might be very much significant. while reading your commit
> log I remembered we had that already, and we had problems with it. cvs log
> and annotate should give you insights.
>
> > box or various one-liners like passing a missing argument to a QString
> > construction.
>
> It doesn't matter how long or how short the diff is. a perfectly looking
> one-liner might deeply screw up everything already. I'm more deciding about
> the significance of the related classes. A simple looking change in KConfig
> might trash the users configuration, even if its just about "calling the
> right constructor".
>
>
> Dirk

["kkeydialog.cpp.diff" (text/x-diff)]

Index: kkeydialog.cpp
===================================================================
RCS file: /home/kde/kdelibs/kdeui/kkeydialog.cpp,v
retrieving revision 1.121
diff -u -3 -d -p -b -B -r1.121 kkeydialog.cpp
--- kkeydialog.cpp	2002/01/29 19:53:27	1.121
+++ kkeydialog.cpp	2002/01/30 03:24:17
@@ -328,7 +328,7 @@ void KKeyChooser::initGUI( ActionType ty
   QWhatsThis::add( m_prbDef, i18n("This will bind the default key to the selected \
action. Usually a reasonable choice.") );  connect( m_prbDef, SIGNAL(clicked()), \
SLOT(slotDefaultKey()) );  
-  m_prbCustom = new QRadioButton( i18n("&Custom"), d->fCArea );
+  m_prbCustom = new QRadioButton( i18n("C&ustom"), d->fCArea );
   d->kbGroup->insert( m_prbCustom, CustomKey );
   m_prbCustom->setEnabled( false );
   //grid->addMultiCellWidget( rb, 3, 3, 1, 2 );
@@ -433,7 +433,6 @@ void KKeyChooser::updateButtons()
 		d->bChange->setEnabled( false );
 		d->bChange->setShortcut( KShortcut() );
 	} else {
-		//KAccelAction& action = pItem->action();
 		bool bConfigurable = pItem->isConfigurable();
 		const KShortcut& cutDef = pItem->shortcutDefault();
 
@@ -447,7 +446,7 @@ void KKeyChooser::updateButtons()
 		d->lInfo->setText( i18n("Default Key") + QString(": %1").arg(keyStrDef.isEmpty() ? \
i18n("None") : keyStrDef) );  
 		// Select the appropriate radio button.
-		int index = (pItem->shortcut().count() == 0) ? NoKey
+		int index = (pItem->shortcut().isNull()) ? NoKey
 				: (pItem->shortcut() == cutDef) ? DefaultKey
 				: CustomKey;
 		m_prbNone->setChecked( index == NoKey );
@@ -470,7 +469,6 @@ void KKeyChooser::slotNoKey()
 	if( pItem ) {
 		//kdDebug(125) << "no Key" << d->pList->currentItem()->text(0) << endl;
 		pItem->setShortcut( KShortcut() );
-		//updateButtons( d->pList->currentItem() );
 		updateButtons();
 		emit keyChange();
 	}
@@ -537,7 +535,7 @@ void KKeyChooser::setPreferFourModifierK
 void KKeyChooser::capturedShortcut( const KShortcut& cut )
 {
 	if( cut.isNull() )
-		d->lInfo->setText( i18n("Undefined key") );
+		slotNoKey();
 	else
 		setShortcut( cut );
 }



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