Hidden features in themes

[IdealData]

I'm having difficulty replicating some of the features provided by the supplied themes, particularly the Enlightened theme and drop down lists.

 

Each state of the drop down (normal, hover, pressed, in focus) can of course have an independent set of display characteristics, however I notice that the enlightened theme drop downs also show the arrow background as a different colour to the field entry area.

 

It's very subtle, but the drop down arrow goes white in hover mode, whereas all other modes are a very pale grey. When I chose a graphic as a fill object then it highlighted this even more. What I cannot understand is:

 

1. Why I cannot create the same effect with the inspector, particularly a different colour for the arrow

2. Why, when I substitute the graphic (scale to fit), the drop down does not lose it's colour properties

3. How did FM create the theme such that it cannot be replicated

 

Any ideas anyone?

[David Jondreau]

I haven't done much with 13 but I saw this in 12. It seems there are some CSS features that are not accessible through the Inspector. You have to copy and paste the element to get the desired effect.

[bruceR]

Does anybody know if we can control scroll bar appearance including width, with FM13 themes?

[LaRetta]

1. Why I cannot create the same effect with the inspector, particularly a different colour for the arrow

2. Why, when I substitute the graphic (scale to fit), the drop down does not lose it's colour properties

3. How did FM create the theme such that it cannot be replicated

 

Any ideas anyone?

 

1.  As David says, some styles are not available (yet)

2.  I have noticed it as well.  Also, in *Enlightened, you cannot make the portal transparent (at least on Maverick).

3.  It is v1 of 13.  They will have these few bugs fixed but not all styles will be available immediately and some maybe never.

 

* I plan to report this if it hasn't already been reported; I just haven't had a chance yet.  :-)

 

In fact, I cannot even CHANGE the background colour of a portal.

[Mark Scott]

Does anybody know if we can control scroll bar appearance including width, with FM13 themes?

 

Hi Bruce,

 

No, the various scrollbar selectors (width, track, thumb, buttons) are not yet exposed in the Inspector. The implication is that, when choosing a pre-defined theme as a basis for customization, it's important to choose one with a scrollbar appearance that matches your anticipated customizations (or at least that you can tolerate).

 

Hopefully this will change.

 

Mark

[LaRetta]

Hi Mark,

 

It appears that it may be the case with portal backgrounds as well.  I had only worked in Enlightened but trying a few other themes, transparent does not work either.  To me, this is unexpected behaviour as transparency worked in 12.  Transparency does work with Classic.  

[pixi]

Does anybody know if we can control scroll bar appearance including width, with FM13 themes?

no, unfortunately any scroll bar param as well as e.g. the calendar icon (of the drop-down calendar) and the arrow icons in the drop-down and pop-up can not be styled (yet).

these elements will remain the same as in the filemaker theme chosen (even if you style and create your own theme.)

 

hth

pixi

[pixi]

 

1.  As David says, some styles are not available (yet)

2.  I have noticed it as well.  Also, in *Enlightened, you cannot make the portal transparent (at least on Maverick).

3.  It is v1 of 13.  They will have these few bugs fixed but not all styles will be available immediately and some maybe never.

 

 

 

 

as said, some graphic elements used are not available to style.

 

to make the portal transparent you have to click on the portal in layout mode and choose:

"Inspector/Appearance/Drop-down below Style", select the "Portal", set the "Fill" color to transparent and then select the  "Portal: Row" and do the same to "Primary", "Alternate" and "Active". this makes them transparent (see the picture enclosed)

 

the custom themes created are "written" in the file and not stored outside (as the original ones). if you want to replicate it just assign it to a layout, change any param and save it as new theme.

 

to create your own theme check out the "ThemeMaker", currently available in the "Filemaker Advent Calendar".

 

hth

pixi

 

 

[Klypto]

Does anybody know if we can control scroll bar appearance including width, with FM13 themes?

Technically, you can if you make a copy of the CSS theme set to the filemaker extensions folder as a custom theme and edit the CSS files.

 

On mac you can see the CSS theme files if you use "open package" on the Filemaker 13 app, then go to Resources > Themes > [Theme Name]

 

Do not edit the files in the App package directly.  (Updates will overwrite or delete your css themes)

 

On mac, filemaker can read my custom css themes in a separate extensions folder without overwriting the originals or tampering with the app.  I have them in Library > Application Support > FileMaker > Extensions > Themes > [Theme Folder Name]

 

 

I use this to load in things like negative values in drop shadows, because for some silly reason the inspector won't allow a negative spread value.

 

 

Some of the CSS selectors for scrollbars are:

 

portal:normal .scrollbar_track {

}

 

scrollbar:disabled .self {

}

 

scrollbar:normal .scrollbar_top_button {

}

 

scrollbar:hover .scrollbar_top_button {

}

 

scrollbar:pressed .scrollbar_top_button {

}

 

 

scrollbar:normal .scrollbar_bottom_button {

}

 

scrollbar:hover .scrollbar_bottom_button {

}

 

scrollbar:pressed .scrollbar_bottom_button {

}

 

scrollbar:normal .scrollbar_thumb {

}

 

 

Note:  Editing the CSS directly is not officially supported by Filemaker and can break or be lost at any time in future versions.

 

 

 

 

Hi Mark,

 

It appears that it may be the case with portal backgrounds as well.  I had only worked in Enlightened but trying a few other themes, transparent does not work either.  To me, this is unexpected behaviour as transparency worked in 12.  Transparency does work with Classic.  

 

They split portal and portal row into two parts of the same object.

 

Right above the selector for states like Normal, Hover, Pressed is a selector for parts of an object.  I was able to get the portal to be transparent on the Enlightened after I made the "portal: row" fill none.

[Claus Lavendt]

A way of getting a little more options on e.g. scrollbars, is to check out how it looks on the different themes. When you find a style (e.g. width of scrollbar) that you like, copy the object to a layout with your custom theme, and save as a custom style. Then you can mix from different themes.

Note that with FM13, the css is being copied into the FM file, so you can not do manipuplation manually there. (which is, anyway, not recommended by FMI)

[LaRetta]

Wow, what a great thread!

 

Thank you, Pixi, for explaining the behaviour change in transparency for portals!

 

Hi Klypto, this is great information :-)

 

Hi Claus, excellent point!  I've been doing this in 12 but it would mean the entire theme was stored which added to file size.  But now that we can copy and save our own styles, it is perfect idea!

[Claus Lavendt]

LaRetta, you are right about FM12.

When you do styling on objects, they get saved as local style on the object itself. Not only does it add to the file size, which is normally not the big issue, but the rendering of the layout is going to be heavy as each object must be rendered individually.

With the new custom styles, you can save the style like a class. All objects with the same style can be rendered together. (not exactly sure they get rendered in one process only, but they will render faster and FM will use less energy)

But that is the big difference.

Also, in FM12, there was really no classes, so that is also why you will see that objects with custom styles, does not render correctly in FM12. (or at least, some objects does not render correctly)

Though it is appealing to style with custom styles and custom themes in FM13 for solutions that runs in FM12, be very carefully. Also, if you have done so and makes edits to the layout in FM12 and save, all custom styles will be "wiped" from the layout. So, in this case, you should really listen to FMI's general remarks about not using new features in previous versions….. and this one is special from the others, where e.g. a popover simply just don't show in FM12.

[Josh Ormond]

With 12 I really liked to copy objects out of the layout, and use something like FileMaker Magazines' Tweak tool to edit the CSS. Then copy back out and past the new styled object. You could create some really nice stuff. But there was some file bloat if you weren't careful.

 

As Claus mentioned, that custom style gets copied on to every styled object, resulting in a load of extra code and slower render speeds.

 

I have found much less need to "tweak" anything in 13. I'm sure I will still do it some, because now you can save the css to the theme and it causes much less code to be generated. But 95% of what I need is already there.

[Claus Lavendt]

 

 

As Claus mentioned, that custom style gets copied on to every styled object, resulting in a load of extra code and slower render speeds.

Just to be clear, I think we both mean "Local styles"….

 

Anyway, I would highly recommend everyone to watch Andrew Paulsen's session; "Surface under the hood", which explains very well, how styles and the underlaying CSS works in FileMaker. I have requested FMI to make his session availble to all TechNet members and while I am not certain, I think I saw this recently on the FMI technet forum. I think it was one of the recorded sessions from DevCon.

And I really think that you should check this out as it will give you a deeper understanding of what is going on. I have heard complaints from developers, that FM12 was slower than FM11. (maybe someone is also having that argue about FM13) But in fact, FM12 (and FM13) is overall faster and much faster than FM11 due to many enhancements. However, where many fails to gain this performance enhancements, is really mostly, because they do not have an understanding of where the problem is. Which in many cases is due to FM having to render objects with local styles. If you convert a solution from FM11, it will get the "Classic theme". While FMI has really done a great job with the converter component, a lot of objects will have local styles and therefore the solution will feel like it does not perform as good as in FM11.

[Mark Scott]

With 12 I really liked to copy objects out of the layout, and use something like FileMaker Magazines' Tweak tool to edit the CSS. Then copy back out and past the new styled object. You could create some really nice stuff. But there was some file bloat if you weren't careful.

 

As Claus mentioned, that custom style gets copied on to every styled object, resulting in a load of extra code and slower render speeds.

 

I have found much less need to "tweak" anything in 13. I'm sure I will still do it some, because now you can save the css to the theme and it causes much less code to be generated. But 95% of what I need is already there.

 

Great points, Josh.  

 

One other new tool that FileMaker 13 provides for managing the file bloat that can potentially come with the new css-based styling and rendering approach is Manage Themes.  This dialog allows you to remove unused themes from a file altogether.  In my testing, removing a theme from a file completely recovered the space taken up when the theme was first added to a layout (i.e., file size shrunk back to where it was before the theme was first added).  Also, FM seems to be much better now about changing themes within a layout without accumulating crud and introducing styling artifacts.

 

Mark

[LaRetta]

Indeed it is much leaner.  When converted from 11 to 12, we all experienced a bloat of almost double file size.  When converting to 13 from 12, that file size remains high but will decrease as you made a change to a layout ... ANY CHANGE.  And it is not just because it happens to compact on that layout ... more goes on behind the scenes.

 

For example, make note of your file size then Save As Compact.  It of course decreases quite a bit so save that number.  Then go to any complex layout and move an object by 1 pt, save the layout and exit.  File size will decrease again.  You can repeat this process with every layout and reduce the file size substantially, bringing it down to less than the 11 version ever was.

 

I am such a fuss-bucket that it would be worth it to me to walk the layouts making a single change to reduce the file size again by half.  I wish there was a way to 'optimise' all the layouts at once.  I have not seen Andrew's session yet!!  Thank you for pointing it out, Claus!  13's lean, mean rendering rocks my boat!

ADDED:  I wonder if making a change to that classic theme (when first converted to 13) and then updating the Classic Theme would force all layouts to re-render more efficiently.  Thinking out loud.  I will test when I get back.

Edited December 19, 2013 by LaRetta

[Josh Ormond]

I'll have to go back and do some testing to...but somewhere along the line the idea was there that you could push the "Theme" styles to all layouts, and updating everything in one swipe. Then again, it's been a busy few months, so maybe I am imagining larger visions. LOL

[LaRetta]

Oh yes, it does do that, Josh!  You can save a theme and all layouts based upon that theme will update.  If a conversion makes all the layouts 'classic' I'm thinking we can make a change to classic and force them all to 'lean up'  LOL.  And it works wonderfully too!  And instant - even with many layouts and complexity!!

[pixi]

Anyway, I would highly recommend everyone to watch Andrew Paulsen's session; "Surface under the hood", which explains very well, how styles and the underlaying CSS works in FileMaker. I have requested FMI to make his session availble to all TechNet members and while I am not certain, I think I saw this recently on the FMI technet forum. I think it was one of the recorded sessions from DevCon.

 

 

 

hi claus,

i'm sorry to say but there is no recorded session from andrew. the recorded one you may refer to is "Containers: Under the Hood" from oleg zaydman.

but in the session andrew hold during his attendance in copenhagen he explained how the styles are working.

and since this was under nda i doubt that there will be any recording of that… sadly!

[Claus Lavendt]

Hi Egbert

 

You are maybe correct that there is no recorded session. (and no, I am not thinking of Oleg's session)

However, Andrew's session does not contain any NDA sensitive informations and I have requested Delfina (at Developer relations) to make Andrew's session available to the community as it provides fundamental insights, that is important to any developer.

She has agreed that it is a good idea, so I am guessing that she has put it on her agenda. Maybe to do a webinar, if there is no recorded video.

But, I would encourage all to request Developer relations at FMI to get this session available. The more requests, the higher it will get on the list….

[beverly]

Technically, you can if you make a copy of the CSS theme set to the filemaker extensions folder as a custom theme and edit the CSS files.

 

"technically" that's correct. However, you must be technically knowledgeable to do it without hosing yourself.

Just be forwarded. Tread with caution!!

[HALBURN]

Can someone please explain where the themes are stored in FileMaker Pro 13 (Mac)?

 

I would like to edit the appearance of the portal scrollbar.

 

Thanks.

 

On mac, filemaker can read my custom css themes in a separate extensions folder without overwriting the originals or tampering with the app.  I have them in Library > Application Support > FileMaker > Extensions > Themes > [Theme Folder Name]

 

 

I use this to load in things like negative values in drop shadows, because for some silly reason the inspector won't allow a negative spread value.

 

 

Some of the CSS selectors for scrollbars are:

 

portal:normal .scrollbar_track {

}

 

scrollbar:disabled .self {

}

 

scrollbar:normal .scrollbar_top_button {

}

 

scrollbar:hover .scrollbar_top_button {

}

 

scrollbar:pressed .scrollbar_top_button {

}

 

 

scrollbar:normal .scrollbar_bottom_button {

}

 

scrollbar:hover .scrollbar_bottom_button {

}

 

scrollbar:pressed .scrollbar_bottom_button {

}

 

scrollbar:normal .scrollbar_thumb {

}

 

 

[Mark Scott]

Can someone please explain where the themes are stored in FileMaker Pro 13 (Mac)?

 

I would like to edit the appearance of the portal scrollbar.

 

Thanks.

 

The nominal answer is:  right-click on the FileMaker application icon and choose "Show Package Contents," then navigate to "Contents > Resources > Themes." There you'll find the CSS files as well as their associated XML manifest files.  The better answer — the one that FileMaker Inc. would certainly give — is "don't go there!". 

 

If you know your CSS reasonably well, modifying it isn't, at first glance, too difficult. They've used pretty standard CSS and have nicely leveraged classes for object styles, pseudo-classes for states, etc. There are, however, a number of quirks unique to the FileMaker rendering environment, such as independent classes for object subparts (e.g., ".row_alt," ".scrollbar_track," and the ubiquitous ".self"). You'll also note from Klypto's list of scrollbar-related selectors that some attributes are part of a specific "scrollbar" selector (with independent classes for such things as ".scrollbar_thumb," etc.), while others (the ".scrollbar_track") go with the "portal" and "text_area" selectors.

 

But beyond that, there are critical issues that are largely beyond your control (as rightly cautioned above by Klypto and others!). One is that any changes to a style-sheet in the Resources folder will likely get overwritten on v-rev updates.  In theory, you could obviate that by saving a copy as separate theme in the Extensions folder, although current support for that is not official and therefore not guaranteed going forward. Also, the XML manifest is critical and its specs are (obviously) not fully known. For example, the theme "<id>" looks like a standard UUID, but whether there are specific requirements for it is not known (even though that seems unlikely). Versioning may also have unknown issues that could make things blow up down the line. And, importantly, FileMaker keeps track of its themes (presumably through the <id> and version numbers) so that they can update them going forward with new selectors for future layout object types (much as Popovers and Slide Controls were new to 13). When you save a custom theme in the "supported" manner (i.e., through the Inspector), it is internally linked to the built-in theme you started with, to provide future-proofing for both new layout objects as well as any changes in the rendering engine's interpretation of CSS. You would likely lose all that if you start mucking.

 

That said, copying a theme to the Extensions folder and editing it might be a good learning experience. Strictly in that spirit, I created an entirely new theme that I was thrilled with, including Mac OS X-style (i.e., post-Lion) scrollbars. Mind you, that was not in a "production" database, and I would not do that personally, nor ever recommend such. It was just a proof-of-concept study in a "throw-away" solution. The exercise helped me understand a lot about FileMaker's themes and styles (although an even better understanding came from Andrew Paulsen's and Adam Ward's excellent DevCon presentations!), so that when I went to develop my custom theme in the supported / Inspector-driven manner, I was able to craft a theme that I was equally thrilled with (albeit without the Lion-style scrollbars).

 

Hope this helps. Meanwhile, tread cautiously, be forewarned, learn, have fun…

 

Mark

[Josh Ormond]

FileMaker Inc is very clear about that point...DON'T touch the themes folder or manually edit the themes. If you don't truly understand how FM is using them and how they work ( this is not a web browser ), you can have a lot of issues, not to mention updates are more likely to break the theme.

 

I'd be more likely to edit the portal itself and the CSS and paste that single object back in, IF it was absolutely necessary.  Honestly, there is almost nothing I've needed to manually tweak since moving to 13. But what is it you want to customize that you can't with the built in tools?

[Wim Decorte]

FileMaker Inc is very clear about that point...DON'T touch the themes folder or manually edit the themes. If you don't truly understand how FM is using them 

 

+1

with a BIG emphasis.

 

FMI has made it VERY clear over the last few devcons that CSS is used but not in any standard way.  So just by modifying whatever CSS code you can find through the FM files, does NOT mean that your changes will be properly translated.

Even worse, whatever translation FM does on that CSS may actually damage your file.

 

So it is not a straightforward CSS --> Layout as you might expect.

[HALBURN]

Thanks for the info and the warnings.

 

I have my big boy pants on and I am willing to take my chances.

[HALBURN]

I tweaked the appearance of the scroll bars in one of their themes when FM12 came out and the only thing that does not seem to be working properly in FM13 is the styling on the new popover buttons is missing. I cannot imagine that changing some of the colors and dimensions of the scroll bars in one of the new themes is going to do any harm.

[Wim Decorte]

 I cannot imagine that changing some of the colors and dimensions of the scroll bars in one of the new themes is going to do any harm.

 

It's all about risk management.  FMI has told us in no uncertain terms not to do it.  They may change something in the next update or the next version that changes how they parse and apply that CSS and it could damage your file.

I would not be willing to risk the integrity of my solution and its data to something like this.

 

You may want to put in a disclosure to your clients that you are doing something that is explicitly unsupported.  Just in case you toast their files and its data and there is no good backup to go back to.

Without that legal protection, personally, I think that would take Hulk pants, not Big Boy pants to do.

[HALBURN]

If FMI is doing something at the display level (where simple edits to a custom theme file could jeopardize the data) then we all have much bigger issues to worry about. 

[Wim Decorte]

No we don't.  As long as we stick to the tools they offer.

Modifying the unexposed CSS is not one of those tools.

 

If that distinction is not clear to you then: godspeed.  And call your insurance agent for a good Errors & Omissions policy

http://en.wikipedia.org/wiki/Professional_liability_insurance

[Mark Scott]

If this is a "production" solution, i.e., for a client or for your own mission-ciritical work, I'd listen very carefully to someone with Wim's level of expertise on this. Also, just to expand on a couple of the caveats I offered above, I sat down with one of the "themes and styles" engineers for 20-30 helpful and highly appreciated minutes at this past year's DevCon, and I have no doubt that the way FM's rendering engine interprets CSS is still evolving, in ways that are likely to break things for you down the line.

 

The latest clue that these things remain in flux is the recent announcement that some of the older built-in themes are scheduled for deprecation (see 13.0v4 release notes). Custom themes derived from those — crafted and saved through the Inspector — will continue to work. That's the route I'd recommend!!!

 

Regarding the potential damage to your file that Wim mentioned, remember that a file is more than just the data; there are various ways it can get corrupted besides at the data level that render it un-openable.

 

One thing you should be able to safely do is copy a theme out of the Reources folder, open that copy up in TextMate, and just study it. You'll come away with a bit deeper understanding of styles and formatting — their complexity, as well as the elegance with which they've leveraged classes, etc. — which may help you when you return to the Inspector to modify things there. I know that after pouring over a couple stylesheets in that way, absorbing the relevant DevCon sessions, and my fortuitous chat with an FMI engineer re these issues, I was able to go back and craft a beautiful (to my eyes, at least), and, hopefully, efficient (from a rendering standpoint) theme through the Inspector.

 

Mark

 

P.S.  If scrollbars are the sticking point, take heart that the trend seems to be for FMI to expose more of those hidden formatting options with each release. FMP12 introduced themes and brought us control over gradients (among other things), while 13 exposed padding and box-shadows. Assuming that trend continues, additional levels of control seem likely in 14, although that's obviously just an educated guess.

[Lee Smith]

I played around with changing themes using the css, in version 12 which is or was a tedious procedure and unrewarding to me. However, I did put my custom themes in a separate folder so that they would be intact in the event of FileMaker upgrading and deleting these in the course of the upgrade.

 

With the reactivation of  this topic today, I got curious about the new custom themes that I have created, as to where FileMaker would be filing my custom themes, and I’m curious  was going to happen to these custom themes when FileMaker upgrades in the future.. 

 

 Looking at the themes via "Show Package Contents”  I do not see any changes to the original themes, nor do I see the name of my custom themes. Does anybody know where FileMaker is putting the customs themes that we create.?

 

Lee

[Mark Scott]

Lee,

 

Custom themes created in FileMaker, through the FM13 "Save as Custom Theme" route, are stored directly in the .fmp12 solution file and, AFAIK, not written out in any way to the application bundle or elsewhere. That's why they included an "Import Theme" button to facilitate moving custom themes between files. It also is how your custom themes get protected in v-rev or full version updates, even if/when the built-in themes themselves are optimized, or just plain deprecated, by FMI. Such custom themes are future-proofed for new layout objects by retaining some sort of internal id linking them to the built-in theme that they started from, so that they'll be able to support new object types. (I don't know whether that process will involve FM writing the styles for new object types into the custom theme embedded in your solution file, or just another level of cascading back to the built-in theme to get their style information. "CSS" should really be named "CCCCSS" for the multiple tiers of cascading going on.)

 

As for the duplicated and modified themes you created way back in 12, and filed into folders you created for them inside the "Contents > Resources > Themes" folder, I wouldn't be at all surprised to see the entire Themes folder get overwritten in updates/upgrades, thus wiping out those internal folders. I've never tested that, however.

 

hth,

 

Mark

[Josh Ormond]

No one is ever going to say it WILL cause a problem. It is a classic case of the Butterfly Effect. A small change when acted upon through various components can have devastating affects on the file.

 

This is what I learned from experience, thankfully on a non-crucial file: Some CSS changes can cause FM to crash. Crashes are bad. Crashes can cause corruption. Corruption is very very bad. One can effectively conclude: Changing CSS in the themes is very very bad.

 

It happened to me on 2 different files. Whether it was CSS impact on the data, or an indirect smack in the back of head, to the data doesn't matter...the file was lost. Gone. Dead.  FMI has not said "alter at your own risk". They clear state: "Do NOT touch the theme files." I believe it is actually part of the license and not decompiling or reverse engineering the source code.

 

I tweaked the appearance of the scroll bars in one of their themes when FM12 came out and the only thing that does not seem to be working properly in FM13 is the styling on the new popover buttons is missing. I cannot imagine that changing some of the colors and dimensions of the scroll bars in one of the new themes is going to do any harm.

[Lee Smith]

Thank’s for the clarification Mark, that makes sense.