[RFC] Possible KView Maintainership
James Richard Tyrer
tyrerj at acm.org
Sat Oct 22 23:14:20 BST 2005
Nicolas Goutte wrote:
> On Friday 21 October 2005 22:48, James Richard Tyrer wrote:
>
>>I am considering volunteering to be the maintainer for KView.
>
> I am not sure but if I remember well there were some issues raised on
> continuing to support KView.
>
The current maintainer said that he could no longer maintain it.
> If I remember well, the main one was there are a few similar applications in
> KDE:
>
> - khtmlimage (kdelibs)
IIUC, all khtmlimage will do is display an image as is at 100% in Konqueror
> - kuickshow (kdegraphics)
>
Kuickshow appears to have been abandoned.
> (And there is also Gwenview, an extragear application.)
>
The Gwenview maintainer is working on it with the intention of having it
included in KDE. It has more features than KView.
> (...)
>
>>My road map for this is to:
>>
>> Make some changes with the 3.x.y version so that it conforms to
>> the current user interface guidelines. I currently have patches
>> for most of this.
>
> If you mean changing in KDE 3.5.x, do not forget documentation freeze. You
> cannot change a GUI that is documented (except if the documentation is
> hopeless outdated anyway.)
>
Yes, I know that there is a freeze on KDE-3.5 till version 3.5.0 is
released. Therefore, I was going to work on 3.4 first. The
documentation for the menus appears to be up to date so it would need to
be updated as well. I presume that lack of conformity to the UI
guidelines is a bug so this could be added for 3.5.1.
>
>> Submit it to Open Usability for recommendations.
>
>> Remove some features to make it less complicated -- target it as
>> JUST the general purpose image viewer (users that want more
>> features now have other choices).
>
> What would make it differ from khtmlimage then?
Mostly, it allows you to change the magnification of the image, rotate
and flip it. If you look closely, you will find that it has some
somewhat hidden features that I never use and which don't work
correctly. Currently you can step through the images in a directory but
this feature isn't 100% stable. I don't know if this is needed or not.
Then there are features which can modify and save images. I don't see
these as necessary. Every app doesn't have to do everything. More
advanced apps do these things better.
> If it is just a few mimetypes, then better add them there.
>
> If it is just a little more, then I would suggest that you get in touch with
> the Konqueror developers (kfm-devel) and try to get a common goal.
>
>> Make some improvements in the UI code.
>>
>> Work on the current bug reports (there are only a few).
>>
>>Then, consider whether it is worth the trouble to port it to KDE-4 and
>>see if someone will help us with the port.
>
> Well, I do not know if it is really worth to do any great work in KDE 3.5.x
> anymore, especially that you would have still the whole porting effort to
> KDE4.
The point of this was more to give new people, including me, something
to work on. I think KView is necessary, it is not a large app, and it
is a mature app which the the maintainer said he can no longer support
so it seemed like a good selection for the project.
> If you really thing that it is needed to keep KView, then may be you should
> start directly with Qt4/KDE4 to be able to use the newest Qt4 improvements.
> (Perhaps also improve it to a mixed QImage and QPicture viewer in the kind of
> the KOPicture class of KOffice.)
The is what we would do if we were experts, but we probably need to
start out with a less ambitious goal.
> Have a nice day!
>
> PS.: I do not know really the state of Kuickshow, especially how much it is
> maintained. (However it is not a simple viewer and will probably never target
> as such. If merged, it would be more in the direction of Gwenview.)
In previous discussions we didn't hear anything from the author of
Kuickshow, so the presumption was that it is an orphan and will no
longer be in KDE when we go to version 4.0.0
--
JRT
More information about the kde-core-devel
mailing list