[Kexi-devel] Kexi namespace for Kexi Breeze icons? "table" term

Sun Dec 13 21:12:10 UTC 2015

On 13 December 2015 at 19:05, Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Hi,
>
> 
Hi Friedrich,

> looking at the proposed new names for the icons as used in Kexi code, some
> of
> them might need more context.
>
> From what I understood, the plan is for Kexi to not rely on any installed
> icon
> theme, but provide any icons itself.
> And the plan of the Breeze icontheme developers is to have each and every
> Breeze icon as part of the official Breeze icontheme.
>
> Which will mean, that Kexi codebase will contain copies of the respective
> icons from the Breeze icontheme. Correct?
> 
>
>
(Below my opinions only, I am not deciding for the project)

There are two approaches:
1. Keep all copies - reduces build dependencies
2. Depend on breeze-icons.git in Kexi.

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.

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.

>
> PREVENTING NAMING COLLOSIONS OF ICONS
>
> For the icons kept in Kexi the icon naming only needs to be unique within
> Kexi. But for the icons in the Breeze iconset, naming needs to be done more
> carefully as all icons are in the global naming space.
> The icons added to the Breeze iconset for some apps have been simply
> namespaced by prefixing them with the app name (like "labplot-" or
> "kdenlive-"). So the same could be done for Kexi as well ("kexi-").
>
> Prefixing by app name though makes reuse by code from other apps less
> appealing, at least that naming makes them seem specific and less general.
>
> Is this the plan here with Kexi icons as well? At least for the start? Just
> asking, so we know what we need to care for with the names.
>

As you know the kexi_ and kexi_ox_ infix isn't up to our standards.
So the idea of using QRC was born to have three things solved in one go:

- 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.

- Poor Qt/framework integration on non-Qt platforms. Wwe don't control that.

- 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.

There are more points but they are more subtle.

>
> If the plan is to make the icons general instead, so other database-centric
> apps/modules would be invited to use them as well, then please read on:
>

For icons born within Kexi mMy idea is to (as soon as any gets mature),
move them to breeze-icons.git:
- 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')
- with database prefix if it's specific to the database domain (example:
database-table, database-query)
- with the 'kexi-' prefix if it's Kexi-specific (hard to imagine many
examples of that for now)

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.

>
> "table" AS TERM IN Kexi-SPECIFIC ICONS
>
> For a consistent icon look, the "Kexi Table Actions" have comments 'Uses
> Kexi's "table" icon'. Which makes sense to me as well.
>
> But at the same time the proposed icon names use the term "table". Which
> poses
> a problem, as "table" is already used as term with many existing icon
> names.
> Which are very possibly used already for all kind of tables e.g. in rich
> texts, spreadsheets or formulars.

Like "delete_table_row" got the proposed new
> name "edit-table-delete-row", which already exists in the Breeze iconset.
> That
> icon is not based on Kexi's "table" icon. And possibly also should not,
> being
> a more generic table and needing to be consistent with the other existing
> "table" icons.
>

>
> What about using the term "db-table" or "dbtable" instead of "table" with
> the
> database-specific icons?
>

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.

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.

Hope that clarifies most things and shows that there's a path is towards
continued good cooperation between people working in particular
subprojects.

BR.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kexi-devel/attachments/20151213/3626bf04/attachment.html>