I'm just starting with development of GTK applications, and took a look at some tutorials along with source code of established projects, and while tutorials designing interfaces use Glade to output '.glade' files, I see source code utilizing '.ui' files.
What is the difference here?
The file extension has no meaning and is best to ignore it but .ui is probably the more reasonable one for you to use though.
Historically Glade used to provide its own format to design UIs and thus .glade was used. Many years ago GTK integrated its own solution called GtkBuilder and Glade was updated to also support this format. No maintained project in 2020 should be using the glade format but many people and old projects likely still use that file extension because the Glade save dialog still defaults to it I believe.
It is possible to build at run time a swing gui directly from a NetBeans .form file? Someting like one can do with xml files generated by Glade to build GTK GUIs or with QtDesigner for Qt GUIs.
Possible? Maybe. Netbeans can recreate .java files from .form files and since Netbeans is open source, something could be done, in theory.
In reality, I have not seen this functionality and I don't think it would be easy to accomplish. Some obstacles that come to my head are:
One must keep in mind that .form files don't preserve information about Java code that controls the behaviour of the interface, (Loading information, Listener's definition and such).
In the default usage of Netbeans GUI builder, components are private to the frame/dialog that cointains them. If we want to handle those componente from outside, the default .form -> .java creation would have to be altered.
Netbeans source code is huge and I would not expect it to be easy to split the required module.
Alternative
I'd take a look at JavaFX and the Java FX Scene Builder to see if they fit your requirements since they have been created with the idea of splitting UI definition and logic.
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.
Being really new to wx, I'm wondering if there is an IDE (especially for Linux) which would help me lay out a frame or dialog or whatever just to help me see what I'm doing. That means also creating the code for those changes.
I remember way back when using resource compilers for OS/2 and Windows that produced binaries that would then create the window, and was hoping for something similar (though obviously not binary if wx doesn't support that).
I use wxFormBuilder. It is written in wxWidgets, so it works on Linux quite well. It can generate C++ code or XRC files. Make sure you understand its philosophy, and use it like this:
generate C++ code for the GUI
don't edit the code wxFormBuilder generated, but create new files
in new files, derive new classes from the classes it generated
implement event handlers in you own class (wxFB creates virtual function for each event handler you wish to use)
I usually name the wxFormBuilder generated classes/files like, for example, MainFrameGUI, and one with implementation (derived one in which I write all my code) would be just MainFrame. This enables you to change the visual layout and regenerate C++ files from wxFB at any time without overwriting your code.
DialogBlocks works quite well for me, although sometimes you need to edit the code to fix errors manually. It has a property editor that seems advanced enough.
Just another options is wxGlade. It does not have the that much features as the others mentioned seem to have, but it works just good enough for me to not daring to switch.
I use Code::Blocks IDE from http://www.codeblocks.org which has
- built-in GUI editor
- Cross compilable, so you can use it under Linux, OSX and Windows.
But I still use wxFormBuilder with it instead of built-in wxSmith editor. But they are compatible with internal wxSmith.
For windows you've got "wx-devcpp" which is Blodsheed Dev C++ with some addons providing what you looking for
Here is project page
http://wxdsgn.sourceforge.net/
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system