Opening documents

Involved development of the OpenMW construction set.
User avatar
Greendogo
Posts: 1292
Joined: 26 Aug 2011, 02:04

Re: Opening documents

Post by Greendogo » 26 Jan 2013, 03:22

Chris wrote:
Greendogo wrote:Also, as far as I know, there is not any difference between the format and construction of ESMs and ESPs, except for their extensions, which dictates how they are treated by the engine and the CS.
I'm not sure about Morrowind specifically, but at least with Oblivion (and early versions of Skyrim) there are actual differences between ESMs and ESPs. There's a value in the header that's set to 1 for ESM and 0 for ESP, and the engine will always load ESMs before ESPs (based on that bit, not the file extension).
Ah, yes, thanks, I forgot about that. This is true in Morrowind as well, that flag is still there, but my point remains the same. There's no difference in the format of the data structure. That value is only a flag to signify that the programs should treat it differently (such as loading it before all the other files and not letting it be the active file when opening it in the CS). That one flag is similar in function to their differing extensions.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 25 Feb 2013, 22:37

Considering the open dialogue related pull requests I am currently getting, there seems to be a lot going wrong. I think we agreed on having separate dialogues for "open file" and "new file" (both re-using the same UI for the most part).

Then there are two remaining issues:

1. There is no need to select a file for editing. As mentioned before, the editor will always edit the last file in the list. For "new file" we obviously need a field to enter the name of the new file. But that is all. No selection mechanism.

2. Both pull requests had master and plugins merged. And apparently that was also shown in the mock-up a few posts above, but I somehow did not recognise that there was no master list anymore. I was probably already thinking of the new file type scheme, which would indeed do away with the old master list UI. But not by merging. We have two options here. Keep the old separated design or switch over to the new one (viewtopic.php?f=6&t=1312).

If we are going for the new one, the new UI can mostly stay, but we still need to undo the merge in the model. A short recap:

Any valid content stack consists of exactly one .omwgame file and zero or more .omwaddon files (I think these are the extensions we agreed upon).

The new UI is good for the .omwaddon files. But we still need an UI for the selection of the omwgame files (probably a combo-box). And obviously the .omwaddon file UI should only list those files that directly or indirectly depend on the selected .omwgame files.

User avatar
pvdk
Posts: 517
Joined: 12 Aug 2011, 16:34

Re: Opening documents

Post by pvdk » 25 Feb 2013, 22:55

The reason my pull request includes a half-finished open dialog for the editor is that I pulled the sel_widget branch because I needed the changes mike-sc made to the data files model. I do believe it is a good idea to have these merged in the model, since it saves us from having two models duplicating information and having to communicate with eachother. If you want to separate the data in the view, then use proxy models.

Another thing that bothers me is the launcher-specific code that sits in components. I reverted it back in my pull request, because it was conflicting with my changes to the datafilespage. My idea was to only have the model in components, nothing else, and manage the views differently. I talked to mike-sc about that, that way we can benefit from the extra columns of data that can be shown in the open dialog. (like dates and file size etc.)

I can have a look at the editor if you want, or maybe mike-sc can do it, but first I need to know how it needs to work and look.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 25 Feb 2013, 23:09

The problem with the editor is that I am still working on it and the open dialogue is a key function I am constantly using during testing. That makes me wary about merging half finished changes to it.
I can have a look at the editor if you want, or maybe mike-sc can do it, but first I need to know how it needs to work and look.
We still have to decide, if we want to switch to the new file concept now or later.

If we do it later, all that needs to be done for now, would be to restore the editor dialogue to the state it was before (basically the same as the launcher dialogue). I guess in this case we can also roll with the merged master/plugin model. But in the long run I do not see how that can have any future.

User avatar
pvdk
Posts: 517
Joined: 12 Aug 2011, 16:34

Re: Opening documents

Post by pvdk » 25 Feb 2013, 23:14

What if I get together a working open file dialog based on the new model for you to use, based on how I would like it implemented, that is: no re-using launcher-specific code in the dialog and with separation of masters/plugins. We can improve it later and you can merge the launchernext branch then.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 25 Feb 2013, 23:15

Sounds reasonable.

graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Opening documents

Post by graffy » 26 Feb 2013, 13:53

Heh... I just figured out how to get the editor to load an esm... then I read this. Ah well.

Anyway, I was kicking around ideas for a recent files list for the startup dialog. There's the traditional 1-click listbox style, common in most MS apps, but after seeing how the open dialog is laid out, I wonder.

Any suggestions as to how a "recent files" feature should be laid out? A thought I had, for example, was if we used a simple list view, would we want to be able to see a list (tool tip or label alongisde) of it's dependencies by clicking on the item before deciding to open?

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 26 Feb 2013, 14:41

I haven't been able to come up with a good idea for the recent files feature. But general thought on this is, that we should be merging it with the profile system, since both a basically doing the same. Maybe implicitly create a profile with a suitable default name, when a list of ESX files is selected for which we don't have a profile yet?

graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Opening documents

Post by graffy » 28 Feb 2013, 04:18

Do you mean simply create a generic "recent files" profile that just lists the names of recently loaded plugins?

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 28 Feb 2013, 09:59

Create a new file with a name based on the edited file. Then list in the recent file list all those profiles that have been used recently.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests