I wouldn't call it a but. I think that most applications don't remember their window position. Indeed, the initial window position is managed by the window manager, not by the application. I would turn this into a wish item, but I event don't know if this something to implement.

You can force the window position with the "Special window settings", so there is no reason to implement this (it would, as you say, break the window manager's positioning algorithm).

The principles of window management technology in X (defined by ICCCM document) give to the window manager the final say on the position at which a window is placed upon creation. KJobViewer can't force the window manager to give it a specified position. It can request it, yes, but the window manager can deny the request.

If you want that a particular window be given preferential position upon creation, use the "Window specific properties" (from KControl or from any window title's contextual menu (see "Configure Window Behavior").

I think there is a misunderstanding here.
Almost all(!) KDE apps remember both their window size and position. This is what is called "session management" which is supported by the KDE API.
With "almost" I mean about five apps installed with my KDE 3.4.2 system don´t remember their window size.

Any news here (regarding my comment above).

Oh, so you mean the position isn't saved between KDE sessions? I'll see if I can confirm this (in which case I guess it would be a bug in the session manager, not kjobviewer).

That´s exactly what I mean :)
I experience this too with some other apps like kaffeine.

Any news? Is there anything special about the way session management is implemented in KJobViewer? I see this problem with KJobViewer and Kaffeine, and with no other apps. I also think this is a bug in the session manager, but I need this info before I can submit a bug report about that.

I don't think KJobViewer has implemented *anything* special in regard to session management.

Hello,

it shouldn't be hard to implement this feature. Just add the functions to the MainWindow, if there aren't allready some.
void writeSettings()
{
  QSettings settings("Organization", "application");
  settings.setValue("geometry", geometry());
}
void readSettings()
{
  QSettings settings("Organization", "application");
  QRect rect = settings.value("geometry").toRect();
  setGeometry(rect);
}

and call readSettings in the constructor of the MainWindow after setupUi
and writeSettings in the closeEvent(QCloseEvent *event) before accepting the event.

Kind Regards

Yes indeed Konstantin

This is why this was marked as JJ. How would you feel about taking this on you? You seem to be quite close to just coding it, testing it and sending patches ofr committing (if you have an account). KDE users would be very grateful to you.

Okay, I will try, but I don't know any coding standards for KDE.
So I'm going to post a patch on success here for discussion.

Greetings
Konstantin

Hah! The solution was easier than I thought,
the applications stores and restores allready it's size. So all I had to do was to replace the storing of its size through its geometry. The source compiles successfully, but I don't know how to set up a testing enviornment, so maybe somebody else could test it.

Here is a diff file for kdeprint/management/kmjobviewer.cpp from kdelibs-3.5.7
diff old_kmjobviewer.cpp kmjobviewer.cpp
105c105,109
< 		resize( conf->readSizeEntry( "Size", &defSize ) );
---
> //     resize( conf->readSizeEntry( "Size", &defSize ) );
> 		QRect rect;
> 		rect.setSize(defSize);
> 		conf->readRectEntry( "Geometry", &rect );
> 		setGeometry(rect);
116c120,121
< 		conf->writeEntry( "Size", size() );
---
> //     conf->writeEntry( "Size", size() );
> 		conf->writeEntry( "Geometry", geometry() );
658c663
< 	if (m_standalone)
---
> if (m_standalone)

Kind regards
Konstantin

Have build and tested it.
Seems to work fine.

I don't know, when the KMJobViewer is a stand alone application, and whether the user want to save the window geometry, if it isn't one.

Good night
Konstantin

KDEPrint in KDE3 is unmaintained and will have no more new features
implemented.  This request will never be implemented in KDEPrint as a result.  

In KDE4 kjobviewer has been replaced by printer-applet which uses
system-config-printer as a backend.  

It appears that printer-applet also doesn't remember its last position between runs or when closed and restored from the system tray (in openSUSE 11.1 KDE4.1.3), unlike say Kopete which does.  This is still a valid request.

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

On second thoughts, it's invalid to re-use this bug for printer-applet, closing and include with other feature request for persistence of all settings.