Bug 158430

Summary: Krita cannot be opened from the command line, to look at files in $PWD
Product: [Unmaintained] koffice Reporter: Theodore Kilgore <kilgota>
Component: generalAssignee: KOffice Bug Wranglers <koffice-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: cberger
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Theodore Kilgore 2008-02-26 02:39:37 UTC
Version:            (using KDE 3.5.7)
Compiler:          gcc-4.1.2 
OS:                Linux

When opened thus

$ krita (enter)

the application disregards the current working directory and insists on giving a file manager/finder which starts from $HOME, instead, and/or it presents the option of opening some previously opened file(s) which may be in some other directory. I have been informed that krita * ought to work, but if there are non-image files in the same directory then it chokes on them and does not seek the specified image files. Example:

Directory contains
      -- some JPEG files, so filter for JPEG is chosen, but also contains
      -- a subdirectory, so krita emits an error message saying that the subdirectory cannot be opened, and 
      -- a bzipped tarball, which krita tries to open and it crashes, and it never gets around to the image files. 

Here is the output of ls for said directory:

genius           genius3               sonix                  sonix_with_post
genius.tar.bz2   genius3.tar.bz2       sonix.tar.bz2
genius2          raw0sonix002_ahd.jpg  sonix006_ahd.jpg
genius2.tar.bz2  raw0sonix002_org.jpg  sonix006_original.jpg
Comment 1 Halla Rempt 2008-02-26 07:48:01 UTC
Thanks, I'll look into it. I suspect it's a problem with all of koffice.
Comment 2 Halla Rempt 2008-02-26 08:02:39 UTC
The other koffice applications have the same behaviour. Setting to the correct product.
Comment 3 Cyrille Berger 2009-09-06 15:16:41 UTC
It still happens. Actually, I observed a slightly different behaviour, it seems to open the file dialog from the directory where the last file was opened.
Comment 4 Thomas Zander 2011-02-05 22:54:03 UTC
The last comment identified the behavior correctly; the open dialog uses the last used dir and not the current directory as the main usage of gui applications is to start it from the start menu or runner.  So we optimize for that and not for the user starting from the command line.

Naturally starting  'karbon mydoc.odg' works like expected.