Version: (using KDE KDE 3.2.92) Installed from: SuSE RPMs OS: Linux Open up Kate. Open up Konqueror. Bring up an FTP site (non Anonymus) in Konqueror. Pick a text file from the Konqueror window and drop it on Kate for editing. You get a pop-up error box saying "Could not read file <filename>". This has not been a problem in KDE 3.2 and previous versions, got only introduced with KDE 3.3.
Is this bug being ignored? KDE 3.3 final is out, but this bug is still there.
The strange thing is that KWrite opens files from non-anonymous ftp perfectly, but Kate does not, complaining it could not open the file (and it displays in the error message not the full URL, only the path). Seemingly Kate cuts off protocol and hostname when trying to open a file from non-anonymous FTP. Anonymous FTP works OK. Most strange is that the window titlebar of Kate (even after opening and closing other documents) still displays the full URL of the file that it refused to open (when selecting the 'Nameless' document in the document selector).
I have the same problem. I open Kate, choose open file, log into my (ftp)account, I open a few files, one at a time and then after a few suddenly I get errors. Closing and restarting kate helps. Opening more than one file at once causes this bug to occur, at least for me. It's very annoying. this bug started with the new KDE 3.3 (aswell as a whole lot of other bugs) cu nicole
I use the sidebar to open files from FTP, and I have no problems. I can confirm the problem when dropping a file from konqueror from non-anonymous FTP, and the same error seems to happen with anonymous FTP. Odd, since no matter how a file is opened, the request should end in KateDocument::openURL()
CVS commit by alund: Dont set textmode on KIO::Job to retrieve a remote file, since it seems that prevents kate from working with non-anonymous FTP sites. I don't understand why kwrite does not set it -- KateDocument::openURL() is called in both apps -- but it does not. CCMAIL: 86851-done@bugs.kde.org M +11 -11 katedocument.cpp 1.752 --- kdelibs/kate/part/katedocument.cpp #1.751:1.752 @@ -1886,4 +1886,5 @@ bool KateDocument::searchText (unsigned bool KateDocument::searchText (unsigned int startLine, unsigned int startCol, const QRegExp ®exp, unsigned int *foundAtLine, unsigned int *foundAtCol, unsigned int *matchLen, bool backwards) { + kdDebug()<<"KateDocument::searchText( "<<startLine<<", "<<startCol<<", "<<regexp.pattern()<<", "<<backwards<<" )"<<endl; if (regexp.isEmpty() || !regexp.isValid()) return false; @@ -2423,4 +2424,5 @@ KMimeType::Ptr KateDocument::mimeTypeFor bool KateDocument::openURL( const KURL &url ) { +// kdDebug(13020)<<"KateDocument::openURL( "<<url.prettyURL()<<")"<<endl; // no valid URL if ( !url.isValid() ) @@ -2471,5 +2473,5 @@ bool KateDocument::openURL( const KURL & // set text mode - m_job->addMetaData ("textmode", "true"); +// m_job->addMetaData ("textmode", "true"); QWidget *w = widget (); @@ -2488,5 +2490,5 @@ bool KateDocument::openURL( const KURL & void KateDocument::slotDataKate ( KIO::Job *, const QByteArray &data ) { - kdDebug(13020) << "KateDocument::slotData" << endl; +// kdDebug(13020) << "KateDocument::slotData" << endl; if (!m_tempFile || !m_tempFile->file()) @@ -2498,5 +2500,5 @@ void KateDocument::slotDataKate ( KIO::J void KateDocument::slotFinishedKate ( KIO::Job * job ) { - kdDebug(13020) << "KateDocument::slotJobFinished" << endl; +// kdDebug(13020) << "KateDocument::slotJobFinished" << endl; if (!m_tempFile) @@ -3941,5 +3941,5 @@ void KateDocument::comment( KateView *, bool removed = false; - if (change > 0) + if (change > 0) // comment { if ( !hassel ) @@ -3969,5 +3969,5 @@ void KateDocument::comment( KateView *, } } - else + else // uncomment { if ( !hassel )
CVS commit by alund: backport fix for 86851 -- dont' use text mode for retrieving remote files. CCMAIL: 86851@bugs.kde.org M +1 -1 katedocument.cpp 1.734.2.5 --- kdelibs/kate/part/katedocument.cpp #1.734.2.4:1.734.2.5 @@ -2459,5 +2459,5 @@ bool KateDocument::openURL( const KURL & // set text mode - m_job->addMetaData ("textmode", "true"); +// m_job->addMetaData ("textmode", "true"); QWidget *w = widget ();
CVS commit by alund: revert; use textmode for now. However, how can we solve the confllict -- using textmode fixes one bug (57623) but causes anotherone (86851). Is there a way we can know if the textmode is required, or is it possible to deduct the error in KIO that causes it to happen? CCMAIL: 86851@bugs.kde.org 57623@bugs.kde.org M +1 -1 katedocument.cpp 1.734.2.6 --- kdelibs/kate/part/katedocument.cpp #1.734.2.5:1.734.2.6 @@ -2459,5 +2459,5 @@ bool KateDocument::openURL( const KURL & // set text mode -// m_job->addMetaData ("textmode", "true"); + m_job->addMetaData ("textmode", "true"); QWidget *w = widget ();
reopened, since I reverted the disabling of text mode in BRANCH for now. I'll try to compile some debug information from kio and kate that from different opens of FTP urls tomorrow.
hmm, I added it because using text mode is the right thing for receiving text files, why this trigger such a nasty bug for non anon ftp I don't know, why only in kate, really not, too, perhaps because wrong widget is set to store auth data? but that wouldn't be a problem of the text mode
What are the encodings of the files refusing to open? Have a nice day!
I'll come up with some proof, but when called from kwrite the textmode isn't set. Possibly neither in other working setups? I'll research more. My opinion is that it's more important to have the drop working with average ftp servers than the text mode for some ancient server.
On Tuesday 28 September 2004 20:18, Nicolas Goutte wrote: > ------- Additional Comments From nicolasg snafu de 2004-09-28 20:18 > ------- What are the encodings of the files refusing to open? any - that is, neither the ascii README nor a utf-8 xml file opens.
On Tuesday 28 September 2004 22:34, Anders Lund wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=86851 > > > > > ------- Additional Comments From anders alweb dk 2004-09-28 22:34 ------- > I'll come up with some proof, but when called from kwrite the textmode > isn't set. Possibly neither in other working setups? I'll research more. My > opinion is that it's more important to have the drop working with average > ftp servers than the text mode for some ancient server. And that ancient server is in EBCDIC perhaps? If yes, we should better modify KCharset to use encoding data from glibc than using text mode. Have a nice day!
CVS commit by alund: Dont use textmode. It's not suitable for many common text encodings, so we won't use it again. If it has to be enabled, it must be settable on a pr transaction bases, in kio? BUG: 86851 M +0 -3 katedocument.cpp 1.734.2.11 --- kdelibs/kate/part/katedocument.cpp #1.734.2.10:1.734.2.11 @@ -2458,7 +2458,4 @@ bool KateDocument::openURL( const KURL & SLOT( slotFinishedKate( KIO::Job* ) ) ); - // set text mode - m_job->addMetaData ("textmode", "true"); - QWidget *w = widget (); if (!w && !m_views.isEmpty ())