What are current most popular solutions for saving OGRE scene in a file? I found the DotScene one, but the last commit there was 4 years ago so it may be quite outdated.
Are there other plugins or mods to save and load OGRE scenes?
The reason why there is no dedicated official scene serialization is, that this is a highly application specific task and got next to nothing to do with Ogre3D itself. For basic prototypes DotScene is the way to go, but many projects will later extend that XML structure to accommodate their own needs which is no difficult task.
You might also want to have a look at Ogitor which is a growing WYSIWYG editor based on Ogre with DotScene support as well as its own format (make sure to either grab a dev build or build it yourself as our last official stable version 0.4 is rather outdated, but we haven't gotten around to do the 0.5 release just yet).
Related
Apple introduced Xcode source editor extensions with Xcode 8.
Will Xcode 8 still support plugins served via Alcatraz?
Xcode 8 prohibits code injection (the way plugins used to load) for security reasons. You can circumvent this by removing the code signing on Xcode. Both of these tools are capable of simplifying that:
https://github.com/inket/update_xcode_plugins
https://github.com/fpg1503/MakeXcodeGr8Again
To work on Xcode 8+ without removing the code signing, plugins will have to be rewritten as Xcode Source Editor Extensions. Unfortunately, the APIs for these extensions only allow for text replacement at the moment, so they are not an adequate replacement.
I've filed a report on rdar, do not hesitate to express your mind as well:
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party
plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being
narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic
source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First
shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
https://github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day
without:
AxeMode – Xcode issues patching Backlight – active line highlighting
ClangFormat – code formatter DerivedData Exterminator – daily need
getting rid or bad stuff FuzzyAutocomplete – name says it all, still
more powerful than Xcode completion HighlightSelectedString MCLog –
console log filtering, including regexes OMColorSense Polychromatic –
variables colouring, cute stuff RSImageOptimPlugin – processing PNG
files before committing SCXcodeMinimap – love this SublimeText-thingy!
XCFixin_FindFix – fixing Find features XcodeRefactoringPlus – patching
Refactor functionality, still buggy, but less than Xcode without
plugin XToDo – TODOs collection ZLGotoSandbox – 'cause dealing with
your folders would be a hell without it
Most of them are not source code-related, thus deserve having a way to
be loaded and working like a charm again.
You can certainly load all your plugins by recode signing Xcode 8.0. All credits to the XVim team. They seemed to solve this problem.
https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md
The Most Important Step From The Solution
There is no support and we can't expect any. Apple decides to shut down the ecosystem around the Alcatraz package manager before they have an api ready (extensions) that is able to do what the plugins were doing before. The extensions are currently limited to the text frame which does not allow to do much.
The main reason announced by apple is security and we can now disable code signing with effort to get back the most important features that were missing in Xcode.
Bad day for the community, bad decision from apple.
I also recommend the discussion on Alcatraz here: https://github.com/alcatraz/Alcatraz/issues/475
Most importantly if you want to support Alcatraz file a bug at http://bugreport.apple.com to make them aware that many people are suffering with this change
I did the same (openradar.appspot.com/28423208):
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day without:
AutoHighlightSymbol - Add highlights to the currently selected token
ClangFormat – code formatter
DerivedData Exterminator – daily need getting rid or bad stuff
FuzzyAutocomplete – name says it all, still more powerful than Xcode completion
KZLinkedConsole - be able to click on a link in the console to open the relevant file and be faster to debug
PreciseCoverage - nicer gui than xcode provides to view the coverage
XcodeColors - shows colors in the console depending on log level (how else should a console be used?)
Most of them are not source code-related, thus deserve having a way to be loaded and working like a charm again.
If you do not make a fast step to support your community i'm sure we
will find another platform to work with.
Seems like this should work. Found some answers here:
https://github.com/alcatraz/Alcatraz/issues/475
The key seems to be to removing code signing in order to get existing plugins to work.
Apparently not :'(
https://github.com/alcatraz/Alcatraz/issues/475
We have to wait until someone convert the plugins into the new Xcode Extensions
First off, I'm brand new to Dojo.
I'm integrating it into our existing web app.
We initially only need the Calendar widget functionality.
I'm looking to keep the number and size of files as small as possible.
I don't believe downloading just the base code file will be sufficent?
http://dojotoolkit.org/download/
Additionally, the Dojo toolkit download is a huge zip (Even if I was to only use compressed files)
Am I left with downloading the toolkit and manually removing everything I don't need?
Is there no custom download builder like jquery ui?
Well, the dojo library is much larger than jquery ui and I don't know of an equivalent to the download builder. If you are just interested in using dojo for a single widget, you might consider exploring a different library.
To use dojox/Calendar, you are still going to need the many dependencies it has on other dojo modules. You can do this manually, but it will be tedious.
One thing you can do is run dojo's build system to package dojox/Calendar and all of its dependencies into a single file. This isn't a trivial task and requires a good understanding of dojo's AMD loader and package system.
If you want to go down this route, I would clone the dojo-boilerplate project on github. It contains everything you need to do this out of the box. Then follow the build system tutorial to understand how you set this up. From there you can have your app depend on dojox/Calendar to produce the file you include on your page to consume it.
I suggest that you put the whole thing (yes, it's a lot of tiny files) to your server.
Dojo 1.9 is written so that when users visit, their computers will only download the individual pieces on an as-needed basis. This is possible because every piece (AMD modules) is explicit about what it needs.
Once you have something that works, you can choose speed-up loading times by using the build system. Basically, this involves going: "If the user wants this thing, they'll probably want all this other stuff, so create a big minified lump and give it to them whenever they start asking." Best of all, it doesn't have to be perfect: If you miss including something, the users browser will still request it a la carte.
At work we're using the Dojo Boilerplate starting application which helps give some initial organization to the build process.
I am trying to build a visualization tool for Decision Trees (and several refinements in the algebraic decision diagram world, once that works) using JgraphT to support the underlying data structures, and JgraphX to throw the structure onto the screen. (I'm new to both packages.)
I gather JgraphX has quite a history-- it seemed as though the Facade and TreeLayout classes from Jgraph 5.13 would be a step in the right direction, but I can't find anything similar in the more recent JgraphX packages. (If I understand the history, Jgraph was renamed to JgraphX sometime after the 5.13 version was released, and the version numbers started over-- is that correct?) Nor can I find the legacy Jgraph 5.13 jar files anywhere.
Specific questions:
Does Jgraph 5.13 exist anywhere, and can someone point me to it?
Does JgraphX support the same tree layout features under a different name or paradigm?
Any help will be appreciated, otherwise I'm going to have to manhandle JgraphT/JgraphX until I have a tree layout tool from scratch, which does not fit my definition of "fun."
JGraphX was a completely rewrite from scratch, which is why we didn't call it JGraph 6 and the versioning started from 1.0.
JGraphX does have tree/hierarchical layouts in it.
Obviously, JGraphT is not a related project to us, so it's unfortunate they didn't update. There is a post on our forum relating to this. I haven't tested the bridge, but the idea is right.
JGraphX does have its own analysis package too, btw. You might want to check whether that meets your needs and whether you need JGraphT at all.
We do provide downloads of the later version of JGraph 5 here.
My suspicions seem to be correct: Jgraph changed significantly in its evolution to JgraphX, and JgraphT hasn't (or won't) catch up to it. Exporting from JgraphT to a Jgraph format works much better if an older version of Jgraph (not more than 5.xx) is used-- then the facades, layout tools, etc, interface properly.
And an older version of Jgraph, version 5.13.00, is found here.
With the tools we have today for assets optimization (for example YUI compressor), how do you automatize it?
For example, I have designed a new website using LESS, so every time I have to edit CSS I have to manually convert them to LESS. The same for Javascript.
So I have to make my PHP project to point to my uncompressed CSS/JS, and when I'm finished, I compress/optimize them, and point my project to the optimized ones again.
I know that there are tools that helps with this (like less.app, which I've used), and that even there are PHP libs that manage all this problem (like Assetic), but I don't like them much. I'm searching for a "programmed" way to deal with optimized assets. Maybe some script that "watches" the uncompressed files or something...
I wish I could have too many alternatives as the Django framework has.
Please, if the question is not well redacted, tell me and we can improve it, so we can establish a good practice for assets :)
I think one efficient solution would be to do this task on the development side, when writting code, and point the code to the optimized files.
One tool that seems to work well is Live Reload (only for OS X, although there is a Windows version on the way).
I like this option as there is no overload on the code to maintain assets.
We are in the middle of a relatively large project which uses ExtJS3 and have already invested ~4 man-years, using several plugins and we have written some plugins ourselfs. After a quick glance at ExtJS4, it seems that we would have a lot of work to do to migrate the project to ExtJS4. Are there any strong reasons to switch to ExtJS4? Currently, it seems to me that compatibility with future browsers (or the lack thereof) is the only one.
We're in similar situation and our conclusion was to wait a bit more as Ext 3 is doing it's job. We experienced many problems in our "test" migration and I would say that it's more a rewrite of the application than a migration :(. Also, our experience showed that Ext JS 4 has some performance problems, forms are a bit different, store cannot reject changes, it's bigger. There are some very good new features like the new class system, mixins, new charts, ...
We have upgraded our application to ExtJS4 without fail.We are happy to say that ExtJS4 is fast compare to ExtJS3.A new class system,mixins,plugin-free charts,focus management...etc.,. But if you want to upgrade you need to change a lot of code because class system and config options are changed.We have tested the performance of our application using ExtJS3 and ExtJS4,so as per our observation ExtJS4 is fast and it will not break.As per our observation,CSS selectors are also changed if you want to customize the component you can easily do the thing in ExtJS4.
We tried to migrate from ExtJS3 to ExtJS4 previous week. Unfortunately I must say it is like translate english to german. A lot of work. From our point of view more or less just the charting system is plus, minus - a lot of components that we use are not supported, a lot of css customization shoud be done, working code in ExtJS3 breaks easily and there is sometimes almost impossible to find an error.
Not an expert but personally I'd start new project with extjs4 but leave exiting project alone. The charting stuff is amazing in 4!