[kde-artists] [Patch] Will Commit::Names for Missing Oxygen icons

Jakob Petsovits jpetso at gmx.at
Fri Jul 4 07:28:43 BST 2008

On Thursday 03 July 2008, James Richard Tyrer wrote:
> I guess that I would like to see actual approval.

Ok, go-*-page icons approved.
go-*-document pending.

> If you feel that we need:
> 	"go-{next|previous}-list
> icons, I see that as a different issue since these are clearly to page
> through a document or something that functions like a document (such as
> a directory containing image files).

(or a PDF containing a list of pages :P.)

Anyways, the go-*-page icons resolve the situation for Okular which has been 
the application in most dire need of such icons. If a demand for -list icons 
(or whatever they're called then) creeps up then let's think about it again, 
but let's not add arrows proactively only because they *might* be needed.
If they're added, they should fill a real need.

> > As far as I remember, the DocumentBack and DocumentForward actions 
> > were added because they clashed with the "global" (Konqueror) ones in
> >  terms of shortcuts and merged menu entries.
> It is hard to determine that.  It looks like in KDE3 that the 'next' &
> 'previous' icons were assigned to "Next Page" & "Previous Page" which
> was an error.  Then the error was covered up by making the CrystalSVG
> icons the same as "forward" & "back"  Since we didn't have a set of 4
> icons for the "* Page" functions, the fix was to change the icon names
> for these Standard Actions to "forward" and "back" and I made CrystalSVG
> icons from someone else's work for them.  There were no Standard Actions
> for the icons: "next" :& "previous" so developers had to add them to
> their application and should have added RTL reversal as well.  It
> appears that in KDE4 that two new standard actions were added for these
> icons.  Perhaps the choice of the Standard Actions isn't correct, but it
> still appears that they should be for these icons.

That is not how I remember it. Instead of guessing, I suggest we ask dfaure 
and pinotree (who were primarily involved in this afair) what the DocumentBack 
and DocumentForward actions actually represent and what the exact motivation 
for these standard actions was. Guys?

> > They still both do the same (go back/forward in history)
> Remember that developers can change the tooltip and use these two
> Standard Actions for something else.  You can use them for "Next in
> List" & "Previous in List"

Like with the "global" go-* icons, you mean? That would even more support my 
point that if there is no more specific meaning to it, we should use the 
generic icons by default. (Remember that developers can not only change the 
tooltip but the icon too :P)

> What you say makes sense, but I don't see it as the issue.  If you think
> that the two Standard Actions are not correct, then you are going to
> need to discuss it with the core developers.

I believe they're correct, I just remember them being a solution for a 
technical problem rather than a user experience one.

> > I won't fight strongly about the go-*-document actions being 
> > reverted, because they won't affect the default look (pinheiro 
> > already noted that arrow icon proliferation in Oxygen is a no-go) and
> >  the effort of discussing that stuff with you is probably not worth 
> > the effort, imho.
> Actually, it is the for "go-*-page" icons that are new.  The icons for 
> "go-*-document" already exist in CrystalClear, CrystalSVG, Kids, 
> KDEClassic, LoColor, KDE3 Oxygen & Technical.  Other icon themes (even 
> GNOME themes -- wonder what they will do with the new names) use the 
> name but duplicate "forward" & "back".

You mean the 1[right,left,up,down]arrow icons? Depending on the outcome of the 
above query, I believe those don't match those document actions but rather 
list navigation in general, whether or not it's on a document level or 

> IAC, there is controversy over these icon names so I will not commit 
> them until it is resolved.

Ok, let's see if we get the document back/forward standard actions explained 
and decide how to proceed afterwards.


kde-artists at kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists

More information about the kde-core-devel mailing list