Bug 260477 - Krita cannot be opened from the command line, to look at files in $PWD
Summary: Krita cannot be opened from the command line, to look at files in $PWD
Status: RESOLVED FIXED
Alias: None
Product: calligracommon
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Calligra Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-26 02:39 UTC by Theodore Kilgore
Modified: 2011-07-04 10:17 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Faure 2010-12-17 19:41:15 UTC


---- Reported by kilgota@banach.math.auburn.edu 2008-02-26 02:39:37 ----

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



---- Additional Comments From boud@valdyas.org 2008-02-26 07:48:01 ----

Thanks, I'll look into it. I suspect it's a problem with all of koffice.



---- Additional Comments From boud@valdyas.org 2008-02-26 08:02:39 ----

The other koffice applications have the same behaviour. Setting to the correct product.



---- Additional Comments From cyb@lepi.org 2009-09-06 15:16:41 ----

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.



--- Bug imported by faure@kde.org 2010-12-17 19:42  ---

This bug was previously known as bug 158430.

Comment 1 Halla Rempt 2011-07-04 10:17:46 UTC
Git commit 064d38390024d88dc8c898f6008c1c87481eed2f by Boudewijn Rempt.
Committed on 04/07/2011 at 11:55.
Pushed by rempt into branch 'master'.

Make sure the file open dialog opens in the dir of the last opened file

Also synchronize the ":OpenDialog" information of KRecentDirs with the
path to any document we have loaded so the file dialog can start in the
right directory.

CCBUG:260477

M  +14   -7    libs/main/KoMainWindow.cpp     

http://commits.kde.org/calligra/064d38390024d88dc8c898f6008c1c87481eed2f
Comment 2 Halla Rempt 2011-07-04 10:17:46 UTC
Git commit e3b34f96f68b3ed752b8069b9d423583a69b88ef by Boudewijn Rempt.
Committed on 04/07/2011 at 12:16.
Pushed by rempt into branch 'master'.

Show the current working directory by default when starting without args

Instead of showing the directory from which we last loaded a file when
we start an app without any arguments, show the directory from which
the app was started.

BUG:260477

M  +8    -0    libs/main/KoApplication.cpp     

http://commits.kde.org/calligra/e3b34f96f68b3ed752b8069b9d423583a69b88ef