[RFC] Icons added, menu guideline conformance improved, additions to toolbars.

[James Richard Tyrer]

Albert Astals Cid wrote:
> About the kpdf changes, can i know the reason for 
> 
> -	m_prevPage->setShortcut( "Backspace" );
> +	m_prevPage->setShortcut( "PageUp" );
> -	m_nextPage->setShortcut( "Space" );
> +	m_nextPage->setShortcut( "PageDown" );

These ( "PageUp" & "PageDown" ) appear to be the standard shortcut keys. 
  My goal here was to get these four apps to be as similar as possible 
and for them to conform to the KDE UI Guidelines.

> IIRC (can't test right now) PageUP and PageDown already work.

I will check to see if they are redundant.

> By removing 
> 
> -        d->aZoomFitWidth->setChecked( checkedZoomAction == 
> d->aZoomFitWidth );
> -        d->aZoomFitPage->setChecked( checkedZoomAction == d->aZoomFitPage );
> 
> your are probably going to break (as said i can't test it right now) the 
> action unchecking when doing this "Click on fitwidth icon, use combobox to go 
> to 50% zoom"
> 
> For rc files, can you explain why are we getting a <Separator/> at the 
> beggining of each menu???? I don't think that does make any sense.

I have found this to be a good practice since it does no harm, but if 
the menu is added onto the end of another menu, then you need the separator.

> Also i'll be glad to know the reasons for the different sorting you propose 
> for the View and Go menu and for the toolbar, a patch that changes sorting 
> without a reason to do seems like "i like it better for no reason so let's 
> change it"

In general, they would have been changed to match the standards or the 
other 3 applications.

The View menu is based on:

http://developer.kde.org/documentation/standards/kde/style/menus/view.html

The Go menu doesn't appear to be correct yet.  OOPPSS :-( I must have 
copied from the wrong XML file.  I will work on it and post a revision. 
  My intent is for it to conform to [The document Go menu]:

http://developer.kde.org/documentation/standards/kde/style/menus/go.html

> I'm not going to review patches for other programs as i have little knowledge 
> and "authority" over them.

OK, but part of the point of this is to have the applications as similar 
as possible.

> Finally and not related to this "bug" because HEAD and BRANCH are probably 
> very similar in that, but it's better to give patches based on HEAD because 
> if you give a patch based in BRANCH the porting work can be so big that maybe 
> it only gets applied to BRANCH and dropped for HEAD.

I prefer to work on BRANCH because it is stable -- doesn't change from 
week to week and it almost always compiles.  If there are porting issues 
to HEAD, I will do them.

-- 
JRT