I have tried using different MindMap diagrams and it looks like this field didn't get enough attention in software development community, so I cannot find enough info on other resources.
Anyway, I use PlantUML to draw Mind Map diagram. The issue is that I draw it from the website, so it gets nested to 6th level and deeper. In PlantUML I can use it either as plain PlantUML or save as PNG file. (It doesn't seem support other formats)
There are several questions but the main is, how can I save/split it as a multi-page?
Sub-questions which also can be answers in my case, how to organise Mind Map to make it readable in PNG? How to keep it on single PNG? Are there other formats supported?
NOTE:
Even though this question asks about specific tool (PlantUML), this question touches fundamental question. I struggle to have this peace ready in my software and it is crucial part before the release.
UPDATE 1:
Here is example of the PNG file I receive after conversion .puml to .png:
NOTE: The .puml file was too long for plantuml.com to render. The length of the file is 16754 lines.
As I wrote in my comment above, SVG representations of a large Mind Map might be more easily navigated:
Try PlantUML using VSCode and this extension: https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml
If you use Local rendering (you have to install PlantUML and configure it on your local machine) you can use large diagrams and produce SVG output. I don't use the IntelliJ plug-in, so I'm not sure if you can also generate SVG with it.
Anyone out there using LiveCode in a multi developer project?
Either way, can someone recommend a good source control system / plugin to use?
We've looked at MagicCarpet but since it is no longer developed we wish to use something else.
Thanks
I'm working on a solution to this problem by exporting the stack file as a structured directory of script, json and image files which will diff and merge nicely in most VCS. It is not yet available but the intention is it will be open source. My goal is to demonstrate it at the RunRevLive conference in May.
Here's the repo for lcVCS https://github.com/montegoulding/lcVCS
I have put a git library stack on revOnline (libVersionControl) that exports to structured xml files that git can handle. It works as far as it goes, but I have hopes that Monte's solution will supersede this effort.
revOnline link to stack
Yes, our team has been using LiveCode with multiple developers. Since the Livecode community is still young, acquiring good source control tools can be a challenge. Our solution has been to break code into modules (stack files). When there are updates to merge into the main codebase, we clone our existing codebase, and merge code changes manually using line by line compare in a text editor. This is not a fun process, but is much less painful than it sounds.
If I were to redesign the system, we would simply use Git (Github.com etc.). There is no reason this would not work with Livecode stacks.
We use LiveCode in a small team with Subversion.
We don't have a perfect solution, but it is very lightweight; we all use a custom extension to the standard toolbar, which among other things has a 'save+backup' button. When we started using it with Subversion, we added code to this button which saves an XML sidecar file for the stack. The file contains all the scripts, custom properties, and optionally fields (controlled by user property in each stack). In our case almost all of our work is in scripts, so this works for us.
The effect is that each time we commit to SVN, we're always committing two files, the LiveCode stack and the accompanying sidecar file - the latter works fine for diffing etc.
Where this lets us down is that we don't have any solution for merging. If we were working on larger systems more actively, we'd also modify I expect look to modify the sidecar format into a complete folder of files. For now however this makes the situation workable (and it takes no noticeable time to generate the sidecar file).
Happy to share code if that was useful.
I know of a tool thats being worked on that is going to really help in this regard. When he showed it to me it looked very functional already. But I'm not sure when he will share it with the community.
So the point is, its just a matter of time before people's stuff comes together to make a turn key solution for this.
Some of us programmers have to deal with graphic files every once and awhile...
Making quick fixes to existing graphics
Throwing together a quick sprite as a prototype
Create an icon because the designer is too busy
I don't think anybody should ever be editing web graphics (jpg / gif / png) directly. They should edit the master file and export over top of the web graphics.
Right now all the psd files in our system are either on the designers or various other peoples drives and if a programmer ever needs to make a proper change they can't without high overhead.
How should I approach solving this impediment?
Save the *.psd / *.xcf files right along side the web graphics *.jpg *.png *.gif so they're easy to find. Either train the Graphic design in source control or have somebody responsible for integration. I tend to like this because it make everything very discoverable and you can just have your web publishing system skip *.pdf *.xcf. However I can also see a coder not liking 2mb psd files crufting up their repository and having to download that on svn update.
Create a separate source control repository or network share for master graphics files.
Continue as is...
Any other suggestions?
I always treat the PSD's used on the projects I work on as source files and the jpegs and gifs that are exported from those PSD's as binaries. Same goes for Word files that turn into PDF's.
My trunk normally has two subfolders:
trunk
/source
/deploy
Everything that doesn't go up onto a server belongs in source folder and everything else belongs in deploy. If I create a database export that serves as a backup then I store it in a sub-folder in the source folder (since it doesn't go onto the server).
There are purists that claim that binary files do not belong in version control. I say that is BS. A PSD is a source file for your jpegs and gifs in the same way a .java file is the source to a .class file. I say, tread it as such.
I'd go for option 2. As you say, the overhead of large PSDs in your source repository is probably too high for comfort!
Have you looked into scripting Photoshop export so that the 'Change PSD file' -> 'Updated graphics on website' workflow is as compact and easy as possible? That'll make the whole enterprise really attractive for everyone IMO; especially if its set to run as a build step on commit.
EDIT: Photoshop seems to support Javascript as a scripting language so getting a satisfying result should be fairly straightforward http://morris-photographics.com/photoshop/tutorials/scripting1.html
Are Adobe's plugin architectures for Photoshop and Lightroom related in any way? If I have source code for a plugin, that works with PS 3.0-CS3 as well as PS Elements 6.0 can I use it with Lightroom directly? If not, what would I have to modify?
No.. lightroom plugins are written in the scripting language lua, photoshop plugins are written in C++.
As noted by kasperjj, the Lightroom plugins are written in Lua so there is not a direct way to convert something from Photoshop over to Lightroom. Additionally, as per the Adobe Lightroom Developer Center, the only features that are extendable in the current SDK are the export functionality, metadata, and web engine functionality.
As pointed out by Rob, the Lightroom SDK does not expose any interface that allows manipulations of the image files themselves. Partly this is because Lightroom is a non-destructive editor. None of the edits made in its Develop module are applied to the original image file; they are applied to the file generated when the image is exported, printed, or used in a web gallery.
That said, there are examples of export plugins that manipulate the image after Lightroom has finished applying its adjustments. In principle, it would be possible to create a host application that loaded a Photoshop plugin and applied it during Lightroom export. It might even be possible to use Photoshop itself as that host application...
Say a development team includes (or makes use of) graphic artists who create all the images that go into a product. Such things include icons, bitmaps, window backgrounds, button images, animations, etc.
Obviously, everything needed to build a piece of software should be under some form of version control. But most version control systems for developers are designed primarily for text-based information. Should the graphics people use the same version-control system and repository that the coders do? If not, what should they use, and what is the best way to keep everything synchronized?
Yes, having art assets in version control is very useful. You get the ability to track history, roll back changes, and you have a single source to do backups with. Keep in mind that art assets are MUCH larger so your server needs to have lots of disk space & network bandwidth.
I've had success with using perforce on very large projects (+100 GB), however we had to wrap access to the version control server with something a little more artist friendly.
I've heard some good things about Alienbrain as well, it does seem to have a very slick UI.
GitHub recently introduced "image view modes", take a look: https://github.com/blog/817-behold-image-view-modes.
We, too, just put the binaries in source control. We use Git, but it would apply just as well to Subversion.
One suggestion I have is to use SVGs where possible, because you can see actual differences. With binaries (most other image formats), the best you can get is a version history.
A lot of the graphics type people will want something more sophisticated than subversion. While it's good for version control, they will want a content management system that allows cross-referencing of assets, tagging, thumbnails and that sort of thing (as well as versioning).
TortoiseSVN can show image revisions side-by-side, which is really useful. I've used it with different teams with a great degree of success. The artists loved having the ability to roll back things (after they got used to the concepts). It does take a lot of space, though.
Interesting question. I don't have a bunch of experience working directly with designers on a project. When I have, it's been through a contractual sort of agreement where they "delivered" a design. I have done some of my own design work for both web sites and desktop applications, and though I have not used source control in the past, I am in the process of implementing SVN for my own use as I am starting to do some paid freelance work. I intend to utilize version/source control precisely the way I would with source code. It just becomes another folder in the project trunk. The way I have worked without source control is to create an assets folder in which all media files that are equivalents of source code reside. I like to think of Photoshop PSD's as graphics source code while the JPEG output for a web site or otherwise is the compiled version.
In the case of working with designers, which is a distinct possibility I face in the near future, I'd like to make an attempt to have them "check-in" their different versions of their source files on a regular basis. I'll be curious to read what others with some experience will say in response to this.
We use subversion. Just place a folder under /trunk/docs for comps and have designers check out and commit to that folder. Works like a champ.
#lomaxx TortoiseSVN includes a program called TortoiseIDiff which looks to be a diff for images. I haven't used it but looks intriguing.
I would definitely put the graphics under version control. The diff might not be very useful from within a diff tool like diffmerge, but you can still checkout two versions of the graphic and view them side by side to see the differences.
I don't see any reason why the resultant graphics shouldn't be kept in the same version control system that the coders use. However, when you're creating graphics using PSD files or PDN files you might want to create a seperate repository for those as they have a different context to the actual end jpeg or gif that is produced and deployed with the developed application.
In my opinion Pixelapse combined with a backup solution is the best version control software for graphics that I've found thus far. It supports adobe files and a bunch of normal raster images. It has version by version preview. It autosaves when the files update(on save). It works like dropbox but have a great web interface.
You can use it in teams and share projects to different people. It also support infinite reviewers which is great for design agencies. And if you want you can publicly collaborate on projects that are "open".
Unfortunately you can't have a local pixelapse server, so for backup my current setup is that I have the Pixelapse folder(like a dropbox folder) inside a git repo for snapshot creation.
With respect to diff and merging, I think the version control is more critical for graphics and media elements. If you think about it, most designers are going to be the sole owners of a file -- at least in the case of graphics -- or at least I would think that'd be the case. I'd be curious to hear from a designer.
#Damian - Good point about the tagging and cross referencing. That's true; while I haven't working with many designers on a software development project, I have worked for a company that had a design department and know that this is an issue. Designers are still (perpetually) looking for the perfect system to handle this sort of thing. I think this is more suited to a design department for shared access, searching and versioning, etc to all assets -- where there is a business incentive to not reinvent the wheel wherever/whenever possible. I don't think it would apply for a project-oriented manner as tagging and cross referencing wouldn't be quite as applicable.
We keep the binary files and images in revision control, using Perforce. It's great!
We keep a lot of art assets, and it scales well for lots of large files. It recognizes binary files, the ones that can't be diffed, and stores them as full file copies in the back end.
It has P4V (cross-platform visual browser), and a thumbnail system so image files can be seen in the browser.
You might want to take a look at Boar: "Simple version control and backup for photos, videos and other binary files". It can handle binary files of any size. http://code.google.com/p/boar/
A free and slightly wonky solution is Adobe version Cue its comes with the Adobe Suites up to CS4 and is easy to install and maintain. Offers user level control and is artist friendly. Adobe has discontinued support though for it which is a shame. Adobe Bridge acts as the client between the user and the Version Cue server. If used properly its an inexpensive solution to version control. I use CS3 version cue with CS3 Bridge. Works great for small teams.