There are discussions about ThemeManager in various places on the net, but I noticed that it's only available in the react-native branch. Seems that it's not in the "next" release. Is this by omission or on purpose?
Thanks
Andy
The ThemeManager component was deprecated starting in v0.15.0 and was functionally replaced by the MuiThemeProvider component.
(source: https://github.com/callemall/material-ui/blob/690cbb4c905a98a5fb50dc9557c87f8ef6807842/CHANGELOG.md#0150-alpha1)
Related
I come from the world of JavaDocs and love the DX of working on a thoroughly-annotated application after a certain level of complexity.
Being able to hover over and peek all the props (and implied types) of a component with some brief documentation would save me so much time instead of having to open up and read through the whole component. Better yet, running a command to generate a documentation site just like you can with JavaDocs would be dope!
Are there any standards or tools built around creating SvelteDocs? I looked through the VS Code marketplace and didn't see any documentation tooling related to Svelte.
I stumbled upon this question in search of more in-depth documentation for the hover/peek documentation method I've been using. It seems that it is not very well documented (ironically) but it is a part of Svelte language-tools and I've been using it for some time with Svelte for VS Code so I'm sure there was more documentation at some point. The way it's used is as follows in your component. I remember reading somewhere that it needs to be the first thing in your component, but I can't find that source anymore.
<!--
#component
some markdown here
-->
For some reasons the only documentation I can find of it is here. But it provides very nice markdown support so you can craft some very informative hover/peek documentation for your components.
EDIT:
Still can't locate official documentation for the #component commenting feature but realized it is indeed described in the FAQ: https://svelte.dev/faq#how-do-i-document-my-components Does this information belong in the actual docs? Maybe.
After more digging, I found just a couple projects for documenting Svelte.
SvelteDoc Parser -- takes a VueDoc approach, based on JSDoc standards, generates JSON documentation for Svelte components
Svelte-Docs -- documentation in Markdown mixed with Svelte's features, can embed components in the generated doc pages
Both look interesting while taking completely separate approaches to solving the issue of application documentation. Perhaps there's still room to build a CLI-based site generator for the SvelteDoc Parser which could be turned into a VS Code plugin!
It is difficult to find a good one. I recommend
https://github.com/carbon-design-system/sveld
It looks very promising. It offers export in Typescript definitions, JSON and Markdown. In my opinion there is only one critical bug left (Markdown generation) so hopefully it can be used very soon.
I recently upgraded from Wicket 7.x to 8.1.0 and wondered what happens to some of the ClientProperties methods, that are now marked #Deprecated without a hint why or what will become of them.
The migration guide doesn't mention them either.
I found this commit introducing the changes, but couldn't trace it back to a Jira story (WICKET-6544 is about buggy user agent detection, i don't see the link here).
So what will become of this feature, will it be removed without replacement?
Thanks for your question: User agent detection was indeed deprecated in Wicket 8 and will be removed in Wicket 9.
I've updated the migration guides, users are encouraged to switch to specialized libraries like https://github.com/nielsbasjes/yauaa now.
While I'm making an Android app, Eclipse will strike out some things. More specifically, Gallery. Here is a screen shot:
When I hover my mouse over the warnings, it says The type Gallery is deprecated. I don't know what Deprecated means, but I do know that it's a Java term. Any help would be appreciated. Thanks!
(From the question before editing: The term is deprecated, not depreciated. It's a common typo, but worth being aware of for searching purposes :)
It's basically a bit like "obsolete" - you're encouraged not to use classes or methods which are deprecated. Typically the documentation will explain why you're not meant to use them, and give you a better alternative. The deprecated version is only present for backward compatibility, usually.
It's worth taking this seriously - a lot of the time if you're using a deprecated API, you're coming at something from a fundamentally flawed approach. Date is the clearest example of this, where the Java 1.0 API was almost entirely deprecated in 1.1, when Calendar was introduced. Using the deprecated methods in Date is a sure way of storing up problems for yourself.
See the Oracle "How and when to deprecate APIs" page for more information.
Deprecated means it used to support older SDK, but not anymore. Thats why you get the warning.
It is just a warning most of the times it works, but you most be careful because it could cause problem with newer versions.
Deprecated isn't a Java term. It is used in many other things but a lot in programming. It simply means that it is no longer supported...normally replaced with something else. The Android Docs will help you adapt it to what you need depending on what you're doing
This chart works fine in Google charts, but when rendered in Eastwood, it doesn't use the 2nd provided color, rather it applies the first color to both bars in the chart.
http://chart.apis.google.com/chart?cht=bvg&chs=150x150&chd=t:18,81&chco=FFF000|00FFFF&chxt=x,y&chl=Bar1|Bar2&chtt=Chart
Any suggestions as to why this could be? Unfortunately it looks like Eastwood is somewhat abandoned.
Confirmed in my 1.1.0 Eastwood installation. It should be noted that the author doesn't have time to do releases anymore, but he's given commit access to others who are patching with bugs regularly.
You can get the latest and greatest with:
svn co https://eastwood.svn.sourceforge.net/svnroot/eastwood eastwood
Unfortunately, the problem is still present in the trunk, and they also broke backward compatibility with Google Charts API (graphs just don't look the same; they tried to add some colorization effects).
I tried to dig through the Eastwood trunk to see what was going wrong, but the code is a complete mess of spaghetti. I don't know enough about Tomcat servlets to do much more debugging right now. Sorry I couldn't be more helpful.
Our small team of 3-4 developers uses a wiki for documentation and collaboration. I'm trying to put together a list of some solid extensions which would help make it better. We are using MediaWiki, but if you know of a good extension/plug-in for another platform I'd like to hear about that too. Thanks.
Here is my list so far:
Geshi for syntax highlighting.
FCKeditor
TagAsCategory
Promising Extensions that don't work w/ MediaWiki 1.15.0
CategoryEditor
IssueTracker
Two things come to mind:
Bug tracking tool integration
SCM tool integration
For MediaWiki there are already
Bugzilla integration:
http://www.mediawiki.org/wiki/Extension:BugzillaReports
SVN integration:
http://www.mediawiki.org/wiki/Extension:SVNIntegration
The whole list of extensions is here
Well, I think that a good starting point would be to check what we use at mediawiki.org, because this is a Development Wiki :)
My first choice would be CodeReview of course. It's not pretty, but it's very useful. See how we use it: it allows to integrate a SVN into the wiki, to add comments on code, tag commits, and put statuses on it.
At MediaWiki, we use new/verified/ok chain, adding fixme/reverted/resolved/deferred when things go wrong; but you're free to use your own statuses here.