I'm using an explainer template (Pixity Land) to create some short animations with After Effects, and use a tool like Bodymovin/lottie to render HTML5 Canvas/SVG animations.
Unfortunately Bodymovin has an issue with the expressions used in Pixity Land, and the rendered animations jump around jitter. I don't have a lot of experience with After Effects and I'd rather not have to re-write the expressions.
I'm wondering if there's a way that I can reduce the expressions to values. Any suggestions?
There is an option to convert expressions to keyframes. (I'm not sure why I was expecting it to be more complicated)
One right clicks on the property that has the expression and selects Keyframe Assistant > Convert Expression to Keyframes (or picks the option from the Animation menu).
Related
I wonder how to draw the lines connecting the items in a QTreeView as illustrated in the picture under Tree Model. My program will run on different platforms and thus use different styles. Can I guarantee that the items are drawn as desired?
I feel, using style sheets might be problematic because certain styles do not print such lines and using a delagate might lead me into issues of double drawing.
There's an example in the documentation here showing exactly what you want to achieve using style sheets.
Please note that when you use style sheets QStyleSheetStyle kicks in, irregardless from the QStyle your application is using at the moment. So if you decide to go this way you will override the look and feel of your control the same way, irregardless from the target platform.
If that is a problem, you may consider to use style sheets only for certain platforms. As an example:
#ifdef Q_OS_MAC
myControl->setStyleSheet(":/my_stylesheet_for_mac.qss");
#endif
Back to the example in the documentation, it uses a few images containing all the various lines (vertical, horizontal, branch, etc) and the ::branch subcontrol and its states to determine which image to use.
The result is something like this:
.
Obviously, you must change the code to show the vline picture instead of the arrows.
As a side node, I may suggest to consider why you want to do this if you are using native styles. If your application has a native look and feel, you should not alter it in any way. That is, if the target platform doesn't render lines to connect tree view items, then you shouldn't add those.
However, if your application is not required to look native across all the target platforms, you may consider using the same style (e.g. Fusion) and deliver the same user experience no matter what the platform is.
Once upon a time I read in some book on an interesting idea of of Source code syntax visualization: they did not use colors like any (average) text editor nowadays does. Instead they tried to format the code like text in a book, thus: using different fonts, font sizes, boxes, bars, indentation etc. The code revealed its task in the way it was formatted, not as it was colored.
A function was basically a new section's headline in large font size (maybe underlined), the argument variables that followed were a dotted list (the example was Pascal code) - or a grey box or something. Loops might had boxes around etc. I can't remember the details, but you might get the idea.
I can not find any trace of projects that tried this again, maybe the benefit was not evident enough or the effort to implement it in some editor was too high (admittedly, it is easier to just use some different color for the same courier font).
But I am still interested whether anybody knows what happened to that idea and these projects or implementations. If you had a parse tree generator front end for a distinct programming language, say, C++, and an engine that generates this pretty printed output from a parse tree (could be done with LaTeX, probably), it might be easy to create some nicely readable code documentation just in black-white.
Edit: an example, basically taken from the TinyXml library.
The code with some common syntax highlighting using colors and a bit italic, underline would look like:
might be, just using grayscale elements like:
There is a Visual Studio extension called TextHighlighterExtension. It was mainly a text colour formatter, but it could be configured with a lot of customisation to change the font type and size as well. This had a couple of defaults where 'class' and 'interface' was increased in size, for example.
I know of other extensions that are similar, if limited in scope - for example, the "I hate regions" extension that appears to fit your question well, or the CodeBubbles concept.
So, I've looked everywhere for a good rainbow parentheses plugin that will give different level parentheses different colors. I really like the couple that I've found, because they both do a good job of customizability while highlighting the right thing. It supports more than parentheses; chevrons, braces and brackets all get highlighted, which I really like.
It seems like there are quite a few plugins for this!; I'm currently using oblitum's because his is optimized for dark backgrounds (I often work straight from the shell).
So, following the tip at the github for that plugin, I have the "always on" snippet in my .vimrc. But when the always on block is above "syntax enable" it doesn't show {} as being highlighted for cpp files. When the always on block is below syntax enable, folding doesn't work. I think its the nature of the plugin that makes it do this; it goes though the file and adds coloration information. I notice that if I use the command :syntax enable after I've loaded the file when its not recognizing folds, then it does recognize the folds. But at this point, it removes the coloration that rainbow parentheses put on it.
In my .vimrc, I have the follow pertinent lines:
syntax enable
set foldmethod=syntax
set foldenable
set foldlevel=100
let g:rainbow_operators=2
au FileType c,cpp,objc,objcpp call rainbow#activate()
I think that, from looking at syntax files that come with vim, such as c.vim, you can see that certain blocks are annotated as folding. I bet that if you could just write a regex based upon it, you could identify characters as syntactic groups. Then you could just define a colorscheme for it. In fact, the rainbow plugin is actually calling "syn region" commands, so I think that this route is very doable, I'm just not that knowledgable with vim scripting.
Can anybody help me modify possibly the plugin or come up with a script or something that achieves both?
Sorry the lateness, I've tried to solve it at Fix disabled folding (issue #2)
I dimly remember having had the same or a similar problem.
Also XML code highlighting was broken IIRC.
I put 'always on' off, and activated the colored parentheses only when I needed it.
So my working solution was just a shortcut to toggle the plugin on and off.
This is a pretty easily explained problem, I'm using FireMonkey to design a form and when I add a TGlowEffect to a tag it ruins the way the Label looks.
If somebody knows how to do this correctly I would appreciate it.
After applying the TGlowEffect:
The text is significantly bolded, and the only affect applied was the blur.
The text only appears like this in the editor, but I would rather it look like it's going to look after I compile.
Maybe I'm just new to FireMonkey and I'm doing something wrong, if anybody has any good reference material on how to work with FireMonkey correctly I would appreciate a link to that also.
If you have not already done so, you should apply update 4 (be prepared for fuzzy fonts though) as I have attempted to reproduce this issue without success with my XE2 (updated to 4). Some more information on what you are actually doing would be useful :-)
As a general thought, rather than adding a glow effect to a label or to a text object, you should change the component style to add a glow effect - this way you can easily apply the same style to other text or labels.
In a nutshell, I want to have different faces for some types of file in dired mode. I don't think it matters, but I am using Aquamacs.
The example I will use here is .tex files. If I can do it for .tex, then I can just apply the same structure to do create other faces for other types of files.
From what I understand, I have to create a variable, write a regular expression, then apply a hook. I read a bit about regex and so far I have
^(.+)\.tex$
I think my structure and regular expression are not really correct. I am not a programmer (though I have an interest on it), I have only been using Emacs for 2 weeks or so, so any help would be greatly appreciated.
What I need is at least the basic structure of what I have to do. I understand there may be modes already created that do something similar (such as maybe Wdired and Dired-X), and I would not complain if someone told me about them, but what I really want is to have an elisp code (either already written or that I can work on), as I plan on learning a bit of elisp to be able to write my own customisations and this would be a way to learn.
Thank you!
Since you want to learn how to do it, try checking out the extension dired+.el. This mode does a lot more than what you want, but it does add new faces. Specifically, look for the variable diredp-font-lock-keywords-1 and how it is used. That should get you going.
Other SO questions that seem relevant are:
Match regular expression as keyword in define-generic-mode
Highlighting correctly in an emacs major mode
A hello world example for a major mode in emacs?