<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 December 2015 at 19:05, Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br>Hi Friedrich,<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
looking at the proposed new names for the icons as used in Kexi code, some of<br>
them might need more context.<br>
<br>
>From what I understood, the plan is for Kexi to not rely on any installed icon<br>
theme, but provide any icons itself.<br>
And the plan of the Breeze icontheme developers is to have each and every<br>
Breeze icon as part of the official Breeze icontheme.<br>
<br>
Which will mean, that Kexi codebase will contain copies of the respective<br>
icons from the Breeze icontheme. Correct?<br>
<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"></div><br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">(Below my opinions only, I am not deciding for the project)</div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">There are two approaches:<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">1. Keep all copies - reduces build dependencies<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">2. Depend on breeze-icons.git in Kexi.<br><br>For Kexi I'm of course preferring 2. since build dependencies for required well maintained components is not a problem. I'd just expect versions present in breeze-icons.git (I did not spot any) or else git date or tag would be checked for minimum version.<br><br>In contrast, for extra build dependencies for Qt frameworks that orginate from Kexi (KDb, KReport, KProperty) isn't a good news. So I'd expect duplication here. Thanks to the fact that when QRCs are used with folders are prefixes, no file is in conflict on build time and runtime. (another +1 for QRC) See also below.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
PREVENTING NAMING COLLOSIONS OF ICONS<br>
<br>
For the icons kept in Kexi the icon naming only needs to be unique within<br>
Kexi. But for the icons in the Breeze iconset, naming needs to be done more<br>
carefully as all icons are in the global naming space.<br>
The icons added to the Breeze iconset for some apps have been simply<br>
namespaced by prefixing them with the app name (like "labplot-" or<br>
"kdenlive-"). So the same could be done for Kexi as well ("kexi-").<br>
<br>
Prefixing by app name though makes reuse by code from other apps less<br>
appealing, at least that naming makes them seem specific and less general.<br>
<br>
Is this the plan here with Kexi icons as well? At least for the start? Just<br>
asking, so we know what we need to care for with the names.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>As you know the kexi_ and kexi_ox_ infix isn't up to our standards.<br>So the idea of using QRC was born to have three things solved in one go:<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- Issues with the current KF explained in a number of threads e.g. on kde-frameworks-devel. Can be 'fixed' one day I believe and this alone would stop me looking for solution but please see two points below.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- Poor Qt/framework integration on non-Qt platforms. Wwe don't control that.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>- A desire for superior startup performance on all platforms including mobile. Run strace for any calligra (kde?) app and you'll see thousands of stat() calls despite icon cache being filled. Or in other words: a desire for not executing unnecessary (IMHO) operations that for complex apps can lead to mixing icon themes and not much more.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>There are more points but they are more subtle.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the plan is to make the icons general instead, so other database-centric<br>
apps/modules would be invited to use them as well, then please read on:<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">For icons born within Kexi mMy idea is to (as soon as any gets mature), move them to breeze-icons.git:<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- with generic name if it's not specific (counter-example: table and query isn't generic name, can mean many things, the same for 'form')<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- with database prefix if it's specific to the database domain (example: database-table, database-query)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- with the 'kexi-' prefix if it's Kexi-specific (hard to imagine many examples of that for now)<br></div> <br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Good news, this leaves very small number of icons within Kexi. Moreover many of what is left can be just symlinks/aliases of Breeze icons. For example a Kexi server project icon.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
"table" AS TERM IN Kexi-SPECIFIC ICONS<br>
<br>
For a consistent icon look, the "Kexi Table Actions" have comments 'Uses<br>
Kexi's "table" icon'. Which makes sense to me as well.<br>
<br>
But at the same time the proposed icon names use the term "table". Which poses<br>
a problem, as "table" is already used as term with many existing icon names.<br>
Which are very possibly used already for all kind of tables e.g. in rich<br>
texts, spreadsheets or formulars. </blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Like "delete_table_row" got the proposed new<br>
name "edit-table-delete-row", which already exists in the Breeze iconset. That<br>
icon is not based on Kexi's "table" icon. And possibly also should not, being<br>
a more generic table and needing to be consistent with the other existing<br>
"table" icons.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What about using the term "db-table" or "dbtable" instead of "table" with the<br>
database-specific icons?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">When
we drop kexi_ and kexi_ox_ infix, the 'table' name and many others
would be in conflict you described, so yes, so as I proposed above either kexi-table of
database-table is the way to go.<br><br>One
clear example why the latter: the KDb framework can get some GUI
components in the future. No surprise they would originate from Kexi but for the naming it should not be critical.
The GUIs may need own default icons, obviously for query and table domains. That
would mean the generic database- prefix would be a good choice, as KDb
tries not to "mention" Kexi at all.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Hope that clarifies most things and shows that there's a path is towards continued good cooperation between people working in particular subprojects.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">BR.<br></div></div></div><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>