When I adjust Pro Motion NG’s window size the docked windows do not automatically adjust to the new size of the parent window. They appear outside of the bounds of the parent window even though they are still docked. This occurs when I left drag the application from the title bar. The same occurs when I double click the title bar to take the parent window out of full screen size.
To adjust the docked windows I can go to Options > Windows > Set Default Layout.
I am using Windows 10.
Yeah, I noticed this after I found the docked windows setting. I assumed it they would move along with the size of the parent window, but no such luck.
I’m not quite certain this is a bug, though. That being said, I would absolutely love to see another toggle somewhere to allow docked windows to follow the size of the main window.
My understanding is that this is the intended behavior, in order to allow working with multiple screens (and especially with tablets like Wacom Cyntique). The end user should be able to (for example) keep on the monitor screen the various panels with tools, palettes, etc., and the drawing area on the tablet-screen, so that he/she can focus on drawing on the tablet, and use the monitor for the previewing panel, palettes, etc.
This kind of feature comes with a price, which is what you’re experiencing — i.e. disjointed windows, independent of each other. To compensate this. PM NG offers menus and shortcuts to quickly arrange panels, and (if I remember correctly) even to store different windows positions configurations, which can then be restored according to need (haven’t used that for a while, so my memory might not be accurate).
I’m afraid there’s no simple way to have this type of flexibility without its side-effects. I also noticed that if you minimize PM NG, many windows remain floating by themselves on the screen.
I’m not sure if it’s possible to change this behavior without enforcing the rigidity that would prevent working with multiple screens.
Have a look at the Options » Windows menu, it contains all the options to re-arrange windows in a smart way, as well as saving and restoring favorite layouts (i.e. different windows layouts for different types of workflows).
Unfortunately, I couldn’t find the description of that Menu in the documentation, it’s not listed in the TOC nor in the Workspace page.
@jan.cosmigo: I tried using the Google search form, but I’ve noticed it doesn’t filter results for the Cosmigo website, but produces just normal Google searches. I’m quite sure that you can customize it to restrict the search results to the Cosmigo domain, possibly even to the documentation pages by restricting results to URLs starting with https://www.cosmigo.com/promotion/docs/onlinehelp/ (i.e. the documentation folder).
Docked windows is on my todo list and once 7.3 is release (still takes time) I will make a poll about what to focus on next. This will be part of the poll.
@tajmone: thanks for the info. Will have a look at this. I tried to find a good JavaScript indexing engine some time back but no luck. Don’t know why there is no engine that creates a simple index on crawled site or html file set and runs per JS in the browser oO
Should not be too hard to code and could be something that lots of people would use.
Google offers an online service to create your custom search buttons for your website:
All you need is a Google account.
I believe there are JS based solutions, but the custom button via Google API seems a more viable solution — it also offers many options on how to show search results.
That’s what I’m using, the Google custom search. And I just tried it on my site to check for a problem. I searches my site as I expect it. Can you tell me more about your search and the results?
When I last checked it (years ago), it showed more Google ads. So, to me it looks good at the moment.
Now it looks fine, beside the sponsored link at the top, all the results pertain only the Cosmingo Documentation — i.e. all results are URLs starting with https://www.cosmigo.com/promotion/docs/.
It looks fine. Most results also seem to use metadata correctly.
I noticed that the documentation pages don’t use the description metadata, which could provide a more neat description about the results entries. But the current results are fine anyway, for Google extrapolates a summary info from the page and uses the doc title for the result heading — but the description metadata could make the results more granular, helping users to better contextualize what’s in that page.
I’m not sure if there are some Google-specific metadata to further optimize results, but I could look into it.
I don’t remember how you manage the documentation sources (I remember that you use the same sources for both the CHM Help and the online documentation). If you’re using Asciidoctor or pandoc you can easily provide the metadata in the documents headers, and both Asciidoctor and pandoc will adjust them according to the output format (e.g. use HTML5 metadata for the website, HTML4 metadata for CHM, the Berlin standard for ePubs, etc.).
Obviously there’s an advantage in using similar tools for they abstract away similar data issues and leave the adaptation work to the converter toolchain, beside allowing separation of contents and styles, and using a format-agnostic lightweight markup syntax that can be converted to any desired format.
Working directly with HTML sources can be a problem due to the CHM Help standard being still fixed on HTML4 (IE 7) whereas the website is HTML5 compliant — unlike the WebBrowser Control, you can’t use the registry hacks for browser compatibility on CHM files (IE11/HTML5), for this would affect every CHM document since it would have to be set on the CHM reader app.
Regarding the differences in the <meta> tag between HTML4 and HTML5, here’s an excerpt from:
5. Schema attribute removed from
<meta>tag in HTML5The
<meta>tag is defined in the header section of the HTML document and contains information about the data. In the previous versions of HTML, including the HTML4, this tag used to contain an attribute calledschemathat defined the schema of the document. However, in HTML5, this tag has been removed.Changes in attributes
Following are some of the attributes that have been modified in HTML5.
- […]
- In the previous versions of HTML, the
<meta>tag didn’t had thecharsetattribute that defines the standard character encoding for the webpage. This attribute has been added in HTML5.
And, if I remember correctly, HTML5 also supports better metadata attributes.
So, there are differences to keep into account when generating the HTML documentation for the CHM Help and the website, in consideration of optimizing search engine result for the latter. Of course, since you probably don’t care much about metadata in the CHM Help, you could just focus on the website, and probably the CHM reader will simply ignore <meta> tag attributes that don’t comply with IE7.
