Create a Category called 'Shared Themes'

I wanted to share a theme i have created so that other users could copy the text and paste in their own custom theme. I however didn’t like the way it appeared in the preview box and thought the theme text flow will be jammed up and unusable by interested users.

I copied a theme someone shared sometime ago and tweaked it to be useful to a client.

So here is the idea, create a category called Shared Themes where users who are good with custom themes can share their themes with other users. I am sure it will go a long way to help users help other users with themes. we will have a big data base of themes where users (New and Old) could find free themes to use in their Manager Businesses. Users will share themes text flow and end result/preview in an attached image. Users will name their custom themes.

I wanted to share the theme I have below

Notice how all the costume field appear above the sales items description box except the bank details and amount in words? it was critical for the client I introduced Manager to to have that appearance with their sales invoices.

So after the category is created, i will share my themes.

8 Likes

love it!:grin:

Very Good Idea

@lubos and @Tut what say you? I need a to know how i can share themes without the texts flow jammed up. And the category for theme sharing isn’t such a bad idea.

Plans are already in the works for more themes. I don’t know how this suggestion would fit with them.

In the same vein, does anyone have any custom reports they would care to share?

You would be creating a pool of User shared themes - rather then a pool of Manger internally supplied themes.
A User creates a theme and posts it to the pool, any other User can then copy that theme externally of Manager.

Yes, I understand what is being proposed. My point was that I don’t know how the additional themes distributed by NGSoftware might eventually be handled. One supposes through the current option under Settings tab. But one never knows. Guides, for example, have gone from separate web site to forum, back to subsidiary web site, and with links from the application now being considered. Change is constant.

I also don’t know what the “official” position would be on providing an environment where anyone could post themes that might not use variables the same way as the built-in ones or be handled by the PDF generator as planned, potentially creating problems for users that would end up as complaints on the forum. Likewise, future application changes might “break” someone’s theme, again with complaints from those who didn’t grasp the full import of any disclaimers.

@Alan1351great idea.

@Tut Yes of course if u copy and use someone else’s theme you may have issues if your HTML knowledge is very limited.

But luckily it wouldn’t mess up your accounting records and if you get lost you can always switch to a default theme to find yourself again.

I for example know only the fundamentals with HTML but after studying the copied Theme I was able to understand the theme and generate more to it especially putting custom fields at where I want them.

I believe with time we will have amazing themes shared here. It will be like an app store.

Everything comes with some risks, especially free things and with this there is an easy way out.

@lubos is a supporter of crowd sourcing.

well you can at least have list of old version Manager with (What fixed or add) inline with theme works until which version.

What I see, user most of the time, not the type always update their software, So if they are comfortable with the version they use, they stay. If there is new addition and fixes in new manager that interested the user, they can lookup what theme is compatible that are tested by early users.

Can you share Invoice template source codes. Like these:-

{{ title }}
            <table style="margin-bottom: 20px"><tr>
                <td style="padding-left: 30px">
                    <div><b>{{ recipient.name }}</b> {{ recipient.code }}</div>
                    <div>{{ recipient.address | newline_to_br }}</div>
                    <div>{{ recipient.identifier }}</div>
                </td>
                <td style="padding-right: 30px; text-align: right">
                    {% for field in fields %}
                    <div style="font-weight: bold">{{ field.label }}</div>
                    <div style="margin-bottom: 10px">{{ field.text }}</div>
                    {% endfor %}
                </td>
            </tr></table>

            <div style="font-size: 14px; font-weight: bold; margin-bottom: 20px; padding: 0px 30px">{{ description }}</div>
        </td>
    </tr>
    <tr>
        {% for column in table.columns %}            
        <td style="font-weight: bold; color: #ffffff; background-color: #C2CBCE; border-bottom-width: 5px; border-color: #AEB6B9; padding: 10px; text-align: {{ column.align }}{% if forloop.first %}; padding-left: 30px{% endif %}{% if forloop.last %}; padding-right: 30px{% endif %}{% if column.nowrap %}; white-space: nowrap; width: 80px{% endif %}">{{ column.label }}</td>
        {% endfor %}
    </tr>
</thead>
<tbody>
    {% for row in table.rows %}
    <tr>
        {% for cell in row.cells %}
        <td style="padding: 10px; text-align: {{ table.columns[forloop.index0].align }}; border-color: #C2CBCE; border-bottom-width: 1px{% if forloop.first %}; padding-left: 30px{% endif %}{% if forloop.last %}; padding-right: 30px{% endif %}{% if table.columns[forloop.index0].nowrap %}; white-space: nowrap; width: 80px{% endif %}">{{ cell.text | newline_to_br }}</td>
        {% endfor %}
    </tr>
    {% endfor %}
    {% for total in table.totals %}
    <tr>
        <td colspan="{{ table.columns | size | minus:1 }}" style="padding: 10px; text-align: right{% if total.emphasis == true %}; font-weight: bold; font-size: 16px{% endif %}">{{ total.label }}</td>
        <td style="border-bottom-width: 1px; border-color: #C2CBCE; white-space: nowrap; padding: 10px; padding-left: 30px; text-align: right; padding-right: 30px{% if total.emphasis == true %}; font-weight: bold; color: #fff; background-color: #C2CBCE; font-size: 14px{% endif %}">{{ total.text }}</td>
    </tr>
    {% endfor %}

    {% for field in custom_fields %}
    <tr>
        <td colspan="99" style="padding-left: 30px; padding-right: 30px; padding-bottom: 20px">
            <div style="font-weight: bold">{{ field.label }}</div>
            <div>{{ field.text | newline_to_br }}</div>
        </td>
    </tr>
    {% endfor %}

</tbody>
<tfoot>
    <tr><td colspan="99">
        <div style="border-top-width: 3px; border-color: #7497A5; font-size: 11px; padding: 10px 20px; background-color: #81A8B8; color: #ffffff">
            <div style="font-weight: bold">{{ business.name }}</div>
            <div>{{ business.address }}</div>
            <div>{{ business.identifier }}</div>
        </div>
    </td></tr>
</tfoot>

@taher, exactly what are you asking, and of whom? Your post was not clear.

This would make the developer responsible for testing every new release against every custom theme posted by everyone in the world. That isn’t going to work.

This presents the same problem. Even if “early users” claim something works, who could rely on that? And what about security?

  1. Shared by all means : use it if it its useful to the user. no responsibilities there. (Shared by user use by users not developers)

  2. Again is the choice of users to continue use it or not. Security? is liquid template code right? and of course backup takes priority before test takes in place.

What I understand about Abeiku only asking specific category to be included in the forum for sharing the theme code.

(Supplementary but not official) You don’t need to include the custom theme in Manager’s software. Unless you decide with the ‘reliable’ shared user to be included in Manager’s software as common template.

@tut can also filter which user’s theme are reliable to get into Shared theme category.

No, @Tut cannot. I am not the developer and do not have the skill or resources to test functionality or reliability of user-drafted themes with all operating systems and Manager modules.

This was my point: the developer may be reluctant to post themes on the forum over which he has no control. Despite any policy, some users will believe that a theme posted here has his approval and should work in all situations. That will lead to complaints, even though it should not. After all, even the four themes built in so far are still turning up bugs.

I suspect he may prefer to limit distribution to themes he can control. By providing the ability to develop custom themes, he has given users the opportunity to develop their own without exposing anyone to potential frustration when someone else’s theme gives a problem. But I am only guessing.

1 Like

I want to get to the point where new themes are continuously added to the program. The reason why I think user contributed themes are a bad idea is that themes will keep evolving. A theme which worked fine 1 year ago might not take into consideration all the new features 1 year later.

The ideal case would be for the program to simply contain 100 or so in-built themes which would be fully supported. This is direction I want to take.

3 Likes

I’m in under impression, the additional built-in theme might not be provided for three reasons:

  1. No distinction of between on-going release and stable release in download sections.
  2. Most of the time @tut answer to users of theme creation or build would be hire professional locals who knows liquid code language.
  3. Custom theme window that shows code for the theme that allow us to fiddle around.

since @lubos had clarified the roadmap for built-in themes. Then, is a long way to go…