On Tuesday 10 May 2005 17:27, Caleb O'Connell wrote:
> I submitted a bug regarding the "get new wallpapers" button in the config 
> desktop area.  It doesn't seem to be saving the extensions to the images, 
> which may be the packages, or config I have with  fedora core 3 box with 
> generic kde packages from kde-redhat.  If you know where in the kde code I 
> can look, I would infact be interested in trying to work on the bug myself.  


kdebase/kcontrol/background/bgdialog.cpp
or the underlying library kdelibs/knewstuff/

bgdialog.cpp:#include <knewstuff/downloaddialog.h>
bgdialog.cpp:           SLOT(slotGetNewStuff()));
bgdialog.cpp:void BGDialog::slotGetNewStuff()
bgdialog.cpp:   config->setGroup("KNewStuff");
bgdialog.cpp:   config->writeEntry( "ProvidersUrl", "http://download.kde.org/khotnewstuff/wallpaper-providers.xml" );
bgdialog.h:   void slotGetNewStuff();

(It's not my code so I have no idea about the bug, feel free to look into it :)

*** Bug 107964 has been marked as a duplicate of this bug. ***

*** Bug 108418 has been marked as a duplicate of this bug. ***

*** Bug 102079 has been marked as a duplicate of this bug. ***

With Bug #102079 it's reported for Gentoo, too, so it is not just a Fedora Core (kde-redhat) problem.
As in #102079 mentioned, the files get the postfix --0 instead of their right extension.

Is there no developer who wants to say something about this? I can't believe that this is so difficult to fix.

Roland: you are welcome to look at my calendar to see just how busy i amm, then look at the release schedule for 3.5. the background dialog maintenance was dumped in my lap recently and i just haven't had the time to even look at it. i have a few irons in the fire as it is, and will eventually get around to looking at this stuff.

if you wish to speed up this bug report, i would suggest finding a developer who has time *right* *this* *moment* to spend some time looking into it.

Hi Aaron, I am sorry for my posting if you understand it as an affront. I was only confused why there was no answer, nothing more!

And I really believe that you have sparse time. I would really appreciate if you can fiy this bug, but if you have not enough time, it would not be the end of the world.

At the moment Caleb (the bug-reporter) is having a deeper look into the sourcecode, maybe he has enough knowledge to solve the problem.

So, thank you for the answer, and don't be annoyed with people like me who are to impatient and ignorant :)

the bad is when i download something in svg format, because all other things could be guessed from header, but not the svg
anyway, it's superb utility which is however used fewer than it could be..

SVN commit 456593 by aacid:

"Usability" fixes
Show the overlay when the user is last or first page and tries to advance or go back
BUGS: 105351


 M  +28 -10    presentationwidget.cpp  


--- branches/KDE/3.5/kdegraphics/kpdf/ui/presentationwidget.cpp #456592:456593
@@ -702,19 +702,26 @@
     {
         // go to next page
         changePage( m_frameIndex + 1 );
+    
+        // auto advance to the next page if set
+        if ( KpdfSettings::slidesAdvance() )
+            QTimer::singleShot( KpdfSettings::slidesAdvanceTime() * 1000, this, SLOT( slotNextPage() ) );
     }
-    else if ( m_transitionTimer->isActive() )
+    else
     {
-        m_transitionTimer->stop();
-        update();
+#ifdef ENABLE_PROGRESS_OVERLAY
+        if ( KpdfSettings::slidesShowProgress() )
+            generateOverlay();
+#endif
+        if ( m_transitionTimer->isActive() )
+        {
+            m_transitionTimer->stop();
+            update();
+	}
     }
 
     // we need the setFocus() call here to let KCursor::autoHide() work correctly
     setFocus();
-
-    // auto advance to the next page if set
-    if ( KpdfSettings::slidesAdvance() )
-        QTimer::singleShot( KpdfSettings::slidesAdvanceTime() * 1000, this, SLOT( slotNextPage() ) );
 }
 
 void PresentationWidget::slotPrevPage()
@@ -723,11 +730,22 @@
     {
         // go to previous page
         changePage( m_frameIndex - 1 );
+    
+        // auto advance to the next page if set
+        if ( KpdfSettings::slidesAdvance() )
+            QTimer::singleShot( KpdfSettings::slidesAdvanceTime() * 1000, this, SLOT( slotNextPage() ) );
     }
-    else if ( m_transitionTimer->isActive() )
+    else
     {
-        m_transitionTimer->stop();
-        update();
+#ifdef ENABLE_PROGRESS_OVERLAY
+        if ( KpdfSettings::slidesShowProgress() )
+            generateOverlay();
+#endif
+        if ( m_transitionTimer->isActive() )
+        {
+            m_transitionTimer->stop();
+            update();
+        }
     }
 }
 

GRRRRRRRRRRRRr sorry did a typo when filling the BUGS: entry

The Problem still exists in SUSE LINUX 10.0 with KDE 3.5beta2, but in this case the file choosing dialog does not depend on the file ending.
But what will happen with svg files?

*** This bug has been confirmed by popular vote. ***

*** Bug 118461 has been marked as a duplicate of this bug. ***

Short status note:

The bug is still existant with KDE 3.5.1 - downloaded files are saved with the string "--0" at the end, instaed of their real file type ending.

However, since the bug was reported the situation changed a little because the file chosing dialog no longer checks for the ending and so you are able to pick the files you've downloaded.
But: this behaviour does not work with svg files which are only identified by the ending - if you pick such a file and want to insert it as a wallpaper, the screen appears empty.

I tried to look into the code and found something suspicious:

QString Entry::fullName()
{
  return name() + "-" + version() + "-" + QString::number( release() );
}


That's line 280 of knewstuff/entry.cpp (svn checkout)

There we have as a return value a name, followed by a stroke, a version number, a stroke and a release number.
But the here reported bug was always about two strokes followed by zero, and nothing else.

I checked http://download.kde.org/khotnewstuff/wallpaper/wallpaper.xml and it turned out that only few pictures are given with a version number - I downloaded one with a version number, and the version number appeared between the two strokes.
The zero at the end could come up because no picture is given with a release-number (according to the xml file).

THe only thing which I couldn't solve was where the file end (like png, tgz or whatever) vanished - I have no idea how to search functions inside such a project :-/

JohnFlux (from irc) helped me digging deeper int o the source code, and he suggested adding this to the code line:

QString ext = payload(langs.first()).fileName().section('.',1).section('#',0);

This should get us the file extension. The file extension itself does not appear in the fullname function because the name itself is setted by parseDomElement using the name tag of the xml file, while the extension only appears in the payload tag.

However, there are still two problems with this suggestion:
1) It is untested - I had problems setting up a clean environment for compiling kdelibs. I will try it again later on, but I shouldn't keep a solution until then.
2) This version only takes the last part after the last dot - that means that in cases of tar.gz files the tar is missing, but tar can be determined by the file headers, so it is not a too big problem...

Created attachment 14860 [details]
It fixes the wallpaper file extension bug in kdelibs/knewstuff/entry.cpp

It's fixed! :-D
I needed a small push from njaard in IRC to understand a compile error in the
right way, but now everything works. The main problem was that the function
mentioned above is not right invocated: it must be langs().first(), not
langs.first().

And you have to add a additional point to get the seperator back into the
filename.

So the difference to the former behaviour is now:
The filename which is constructed of different information of the xml info file
gets an additional point and then everything of the original filenmae after the
first dot.
That makes sure that even constructions like jpg.tar.gz are recogized and
downloaded right.

The only disadvantage is that filenmes like foo.bar.jpg will be renamed to
nmae--0.bar.jpg - but that's something the user can live with, I think :-)

SVN commit 620538 by mkoller:

BUG: 105351

Keep file extension after download of the payload.
Don't use version/release info to generate fullName() if it's not set



 M  +4 -1      entry.cpp  
 M  +10 -4     knewstuffgeneric.cpp  


--- branches/KDE/3.5/kdelibs/knewstuff/entry.cpp #620537:620538
@@ -286,7 +286,10 @@
 
 QString Entry::fullName()
 {
-  return name() + "-" + version() + "-" + QString::number( release() );
+  if ( version().isEmpty() )
+    return name();
+  else
+    return name() + "-" + version() + "-" + QString::number( release() );
 }
 
 QStringList Entry::langs()
--- branches/KDE/3.5/kdelibs/knewstuff/knewstuffgeneric.cpp #620537:620538
@@ -87,11 +87,17 @@
 
 QString KNewStuffGeneric::destinationPath( KNS::Entry *entry )
 {
-  QString path, file, target;
+  QString path, file, target, ext;
 
   mConfig->setGroup("KNewStuff");
 
-  if( entry ) target = entry->fullName();
+  if ( entry )
+  {
+    ext = entry->payload().fileName().section('.', 1);
+    if ( ! ext.isEmpty() ) ext = "." + ext;
+
+    target = entry->fullName() + ext;
+  }
   else target = "/";
   QString res = mConfig->readEntry( "StandardResource" );
   if ( res.isEmpty() )
@@ -100,7 +106,7 @@
     if ( !target.isEmpty())
     {
       res = "data";
-      if ( entry ) target.append("/" + entry->fullName());
+      if ( entry ) target.append("/" + entry->fullName() + ext);
       else target.append("/");
     }
   }
@@ -117,7 +123,7 @@
   if ( !path.isEmpty() )
   {
     file = QDir::home().path() + "/" + path + "/";
-    if ( entry ) file += entry->fullName();
+    if ( entry ) file += entry->fullName() + ext;
   }
   else file = locateLocal( res.utf8() , target );