[portej05]

kara: Remind me to add versioning to the list of requirements.

[The E]

We're currently in the phase where we're tossing ideas and concepts around. And again, this is a new project, which is separate from FRED.
At this point, we're not saying that FRED needs to (or even should) be replaced completely by it, we just want to build something that does everything that FRED does, and a little more. Integrating this as seamlessly as possible into the FSO project is pretty high on the list of priorities.

[Fury]

I think you guys need to cool down a bit.

* Fury  pours some cold water on the topic

While I'm no coder, I'll still say that portej05 and rest of his merry folk can start their new ambitious project if they so want. You can criticize the project all you want but please refrain from inflammatory posts. In fact, I encourage criticism as it often brings about real issues that needs to be dealt with. If they pull this off, we will have really awesome tool in our hands. If they fail, nothing except their personal time they used to work on the project is lost. Even then, they have learned much from it and can carry that knowledge on to other projects, such as the good 'olde fred2_open.

When it's all said and done, it's the community that chooses what tools they use. If this new project proves its worth, that's what the community will move over to. If not, the community sticks to fred2_open. Alternatives, diversity and different philosophies can be an asset in the long run.

And my 0.5C concerning wxwidgets vs. qt. Whichever has the better IDE(s) and costs less should be used and that seems to be qt. On that note, whatever you guys work on, please try to ensure it will compile on Visual Studio Express as it is yet another major cost factor. The less money required, the more potential coders we can get and less issues with outdated VS like VS6.

[Zacam]

(In the following post, there may be statements of irrationality or so common sense that they are tacitly understood. Comment on the irrational bits, but don't point out the tacitly understood points just to say that they are already understood.)

FRED is _sort of_ possible in VS'08 Express.
Unfortunately, it's a bit complicated and requires adding more things into the SVN that would need to be maintained and is essentially static linking.

Granted, it's ATL/MFC support which _shouldn't_ be seeing too many updates, but even still, it would be a pain in the ass to implement and god help if it ever decides to barf all over itself because something in /code changes.

Myself, while I'm not the most rational of people, believe in the following:

Whatever version of "FRED" gets made should be supported within the existing compilers, including the free Express editions. I don't feel like adding yet another IDE, SDKs, etc to my system and I don't think it's fair that we make new and interested folk have to go through doing it either.

That being said, I realize fully well that said task as above may not be entirely feasible. Therefor, whatever alternative is selected should be as hassle free, self contained and as free for anybody to get and use as possible. If I have no choice _but_ to have to utilize another IDE, I want the impact to be as minimal as possible, not just because I'm lazy, but because being able to provide support and assistance to others will be easier to accomplish.

I like there being alternatives and different perceptions on approach. Sometimes, as Kara pointed out, these are not always optimal especially if you are in a position that it may force you to relearn a system you have already established and know better than anybody will ever know you.

And I definitely see the point in having anything externalized that requires constant maintenance. As already stated, a recipe for disaster there. So make sure the system has some way of being able to invisibly (and securely) update itself.

As far as I am gathering, the two ideas are thus:

1: Portability of the existing FRED as it stands to working on other platform OSes. Then maintain the cross compatibility while working in new features before addressing any feature UI changes or adjustments (eg: Undo). Preferably the goal is to also make it so that it can compile in other OSes as well. Contenders on the IDE are wxWidgets and QT, is there any VS possibility?

2: Starting with the UI and the underlying end-result concept, draft a new FRED-replacement that does what the current FRED does, but starts out already being cross platform (hopfully, otherwise what's the smegging point?) that can incoperate as well additional features not already present (again, such as Undo). wxWidgets and QT also present as alternatives here, again a question of VS support possibilities.

So, what terms do both of these have in common?

Final product to be Multi-platform/OS capable. Must offer the same features across the builds as well as optimally, the same UI presentation to make work migration betwixt them easier.

Compilation under one IDE. _Which_ IDE seems the current hot-collar topic, so it'll just be plainly stated here without digression.

Must support all current capabilities as existing FRED (or at the very least, Retail Fred to start with from a Proof/Beta Release) Porting FRED makes this one a lot easier to achieve in some respects, only because the features are already there, but it's still no walk in the park. A new project/code base has a lot of catching up to do.

Learning curve of the final release product. The Exe itself. Many people are already familiar with the existing FRED interface. Many folks use the keyboard shortcuts as naturally as breathing by now, probably. But there may also be just as many people (and the two camps are not exclusive of each other) that feel that things could be laid out better or be more visible/easier to access/etc. But a completely stark new interface may be completely over-whelming if it doesn't carry over any common elements.

I see, from where I'm sitting, a dead heat between the pro's and con's for both positions. And ultimately, what I'd like to NOT see, is either position becoming mutually exclusive of the other. We're not working cross-purposes here, even with the ideas being in (apparent or perceived) conflict of each other.

[karajorma]

When it's all said and done, it's the community that chooses what tools they use. If this new project proves its worth, that's what the community will move over to. If not, the community sticks to fred2_open. Alternatives, diversity and different philosophies can be an asset in the long run.

Unfortunately it's not quite that simple. Suppose this new IDE gets built and it's just as big a PITA as I suspect it will be. Now suppose I want to add a new feature to FS2. I do that, then I added it to FRED. Now I have to go and add it to this program as well.

What I can quite easily see happening is one program lagging behind the other or worse, both having different compatibilities with different features. We've spent the last few years trying to get away from the 3.5.5 nonsense where we continually had to tell end users to use recent builds in order to get around basic problems. I'm certainly not keen on seeing a return to that kind of stupidity. Especially if we inflict it on ourselves.

Which is why I think an approach that results in only one tool is the sensible one.

[Spicious]

wxWidgets does not have a free IDE that allows WYSIWIG editing of the interface, which at least for me is a major drawback.

http://lmgtfy.com/?q=wxwidgets+rad

What I and a few others would like to do is to build a sort of FS IDE, which offers a unified interface to all aspects of FS modding. And frankly, you and Goober naysaying every idea and concept that is developed for this is not helping.

They all seem to be horribly infeasible in ome way or another.

[Zacam]

Spicious: Better would have been:

http://www.google.com/search?q=Free+wxWidgets+IDE

And even better is:

http://wiki.wxwidgets.org/List_of_Integrated_Development_Environments

Wherein I direct people to see: "wxVS2008Integration - Proprietary wxWidgets Project wizard and Plugin for Visual Studio.NET 2008. "

[Spicious]

When did complete integration with visual studio become a requirement?

[Hery]

I really don't like the fact Qt requires user to install additionall framework. wxWidgets seems to be a better solution, but again, there are problems with convenient WYSIWYG editor. However, if the possibilities of wxWidgets are similar to the possibilities of Qt, I would rather opt for wxWidgets. (That's only my opinion based on what I've read about wxWidgets since I haven't used that framework).

There's no way we can make FRED and FS totally independent, that's what karajorma said. There are no advantages of such a solution, only disadvantages. On the other hand statically linking code.lib is a waste of space (especially when we are considering removing jpg support to save space). IMO we need here dll (or so for Linux and Mac OS X) file that will be shared by FS and FRED.

As The_E mentioned before I've proposed making FRED a big tool that will cover many aspects of modding (especially tables modifications) apart from creating missions. That's hard to achieve but I think we can do it.
If we base UI on dockable panels (http://www.hard-light.net/forums/index.php?topic=63215.msg1292866#msg1292866) then we can easily take advantage from plugins system. Each functionality (for example tables editor) will be just another plugin (dll or so file). Plugin manager will be in exe file (probably together with few additional, hardcoded functions). Then our first task will be to create plugin manager and first plugin: mission editor in order to restore original FRED functionality. Afterwards we will be able to add new tools. (New plugins will be able to create new dockable panels, so integration with UI will be quite easy).

Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).

We have to rewrite FRED anyways if we want to make it portable. We can't keep old UI, that modders get used to, for ever. That's great opportunity to make FRED much better than it is now. It will require a lot of work, but in a long term it will make many things easier.

[Tomo]

As The_E mentioned before I've proposed making FRED a big tool that will cover many aspects of modding (especially tables modifications) apart from creating missions. That's hard to achieve but I think we can do it.
If we base UI on dockable panels (http://www.hard-light.net/forums/index.php?topic=63215.msg1292866#msg1292866) then we can easily take advantage from plugins system. Each functionality (for example tables editor) will be just another plugin (dll or so file). Plugin manager will be in exe file (probably together with few additional, hardcoded functions). Then our first task will be to create plugin manager and first plugin: mission editor in order to restore original FRED functionality. Afterwards we will be able to add new tools. (New plugins will be able to create new dockable panels, so integration with UI will be quite easy).

That's basically what I've had in mind for a while.

Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).

Eg QCommand for Qt.

We have to rewrite FRED anyways if we want to make it portable. We can't keep old UI, that modders get used to, for ever. That's great opportunity to make FRED much better than it is now. It will require a lot of work, but in a long term it will make many things easier.

Indeed.

The reason I started the other thread was to try to have a full discussion about such a FRED IDE base framework, and determine a suitable architecture.
- I think we should split over there.

[Hery]

Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).

Eg QCommand for Qt.

I should expect something like that in Qt since there are only few thing they don't already have ;P (what about QFRED? ;P ) It can be very useful but I don't think is a sufficient reason to choose Qt instead of wxWidgets.

[portej05]

ya know, I was having a chat with a respected member of the community earlier today, and realised something.
We're going about this all arse-backwards.

My mummy (well, my coding mummy) always told me to decide what you want to do before deciding on a framework.
To that end, I suggest we stop bickering about frameworks and linking and start developing a forward looking plan, including UI designs, data management designs, etc - basically, a full requirements spec. This project is going to go nowhere quickly if we don't start thinking about what we're actually trying to achieve.
Once we've accomplished that, we should then evaluate the frameworks based on what they have to offer us in terms of ease of coding (yes, you heard me, ease of coding) what we've designed, rather than focussing on users and their installation woes.
The final step should then be to have someone figure out the distribution issues.

So, to that end, I suggest starting to develop UI ideas and requirements in a framework agnostic manner, and keeping the discussion from here on constructive, productive and polite.

[Tomo]

You're absolutely right.

So, some suggestions:

The basic view should be a 3-pane view with top toolbar and menu.

The left-hand pane contains a treeview of the Mod, (not a mission or campaign) and extends the full height of the window.
(It needs to be tall because there's going to be a lot of stuff there)

• The top-most Node states the Mod Folder. This makes it easy for a user to know exactly which Mod they are using.
• Subnodes show Campaigns, Missions, Ships and other assets (eg tables) available by virtue of the selected Mod.

The bottom "Editor Pane" contains the properties of the currently selected 'item', and can be used as an editor if appropriate.
- Note that not all items will be editable, but it should be possible for a later developer to add an editor for any item.

The final "3D Pane" of the shows the currently-chosen mission, very similar to how it's currently shown.

All of these panes should be resizeable.
The 'Editor' and '3D' panes and can be hidden or 'torn-off' and placed external to the main window, or redocked to a different edge.
- For example, a user might want to make the Events Editor fullscreen and put the 3D Pane onto their second monitor.

Usage Example:

• To add a Ship to the mission, a user drags and drops a Ship Asset from the treeview into the 3D Pane.
• This ship is then added as a subnode within the currently active Mission in the treeview and is selected
• The Subnode is labelled with the in-mission name of the ship
• With the in-mission Ship selected, the Editor Pane shows and can be used to edit its flags, orders, settings etc. Some of these may be considered 'subnodes' of the ship itself (TBD)

[Goober5000]

That node tree approach is how PCS2 works, and I'm not really a fan of it.  I much prefer the dialog method.  One dialog per area of design.  Though the dialogs shouldn't be modal.

[Tomo]

It might be worthwhile to notice that users of FRED will still want to use versions prior to 5606, due to a waypoint bug caused by fixing WMC's warp-code..

I'll be posting a private build soon that does not include the changes to waypoint system, while still allowing Sync "Lost" to proceed as intended. It will contain all the other latest updates as an interim solution until FRED get's fixed.

Incidentally, this post indicates the benefit that would be gained from (at least partially) separating the two projects.
- There's bits that evidently need to remain linked, such as the POF loading code.

At present, changes to FS2 (even changes that should be completely unrelated to the editor at all), sometimes break apparently unrelated parts of the editor.

The suggestion of an autogenerated configuration file handles the requirement to keep new features 'in sync'. (Be that XML, a table file or whatever)
- That file could of course be a compiled-in resource, as it is in a couple of programs I use at work.

[karajorma]

But as I've said several times that is quickly balanced out by the fact that you now have two different routines to do the same job in two programs.

[portej05]

While I'm not intending to continue this discussion too much further - this really isn't a planning thread, think about the opportunities for autogenerated code by storing meta data - reduce three sets of maintenance to one.

[Spicious]

Am I the only one reminded of Softcoding?

[portej05]

Am I the only one reminded of Softcoding?

Done properly it actually saves a lot of time - I've used such a technique to generate masses of interface code between multiple compilers and languages (FORTRAN/C).