Bug 82195

Summary: Ignore qt/kde args in kcmdlineargs when noKApp is true (with patch).
Product: [Frameworks and Libraries] kdelibs Reporter: Kurt Hindenburg <khindenburg>
Component: generalAssignee: Unassigned bugs mailing-list <unassigned-bugs>
Status: RESOLVED INTENTIONAL    
Severity: wishlist    
Priority: NOR    
Version: SVN   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Patch to ignore qt/kde command line options when noKApp == true

Description Kurt Hindenburg 2004-05-25 19:40:46 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

Background: I'm trying to remove the qt/kde command-line options from konsole.

KCmdLineArgs::init( argc, argv, &aboutData, true ); // Disable qt/kde options.
[...]
KApplication a;

However, konsole dies with it hits the KApplication line.  This is because
a KApplication expects to have qt/kde options.

This patch checks for noKApp in the qt_ functions in kdelibs/kdecore/kcmdlineargs.cpp to solve this...

This appears to work O.K. in konsole.

If there is a better way to do this, let me know!
Comment 1 Kurt Hindenburg 2004-05-25 19:42:45 UTC
Created attachment 6120 [details]
Patch to ignore qt/kde command line options when noKApp == true
Comment 2 Waldo Bastian 2004-05-26 11:27:35 UTC
I don't think this it is desired to remove _ALL_ Qt/KDE command line options.

Which Qt command line options don't work in konsole? Do they work in other KDE applications?
Comment 3 Kurt Hindenburg 2004-05-26 16:38:26 UTC
1.  KCmdLineArgs::init( argc, argv, &aboutData, true ); 
noKApp - Set this true to not add commandline options for QApplication / KApplication 
Doesn't setting noKApp to true, mean you don't want any qt/kde options?

2. Reconsidering, I don't think konsole can use this init(,,true) line.  
I had thought about adding a function KCmdLineArgs::removeSpecificArg(id,
name).  Perhaps I should consider that.  ie removeSpecificArg("qt", "background")
Comment 4 Waldo Bastian 2004-07-29 14:45:39 UTC
I don't see a need for this.