pvdk wrote:
Could someone assign the OpenMW Launcher task to me? I'm working on a drop-in replacement for the original Morrowind Launcher. So far the Data Files dialog, where you can select your master and plugin files is mostly done.
The dialog reads and writes the Morrowind.ini file, so selecting plugins already works. What needs to be added is some information about the files, such as creator and parent files etc. Here is a little teaser:

My version in KDE style:
My version in Qt's Windows-ish style: (note: not on Windows)
The original:
Oh and before I forget it: it's written in Qt so completely cross-platform.

For now: have a nice weekend!
pvdk

Zini wrote:
We will have to look more into the details. First, we are not using Morrowind.ini (btw. we don't support plugins at all atm.). Also, I am not sure, if it is a good idea to simply copy the original launcher's user interface. Its been a while since I used it, but from what I remember the usability wasn't too great. I don't think we are obliged to produce perfect copies of external components like the launcher.

You can have this task, if you want, but IMHO its a bit early for it.

pvdk wrote:
Yeah I know the launcher isn't too useable and I know it doesn't have to look like the real thing but I wanted to simulate the whole thing first, get something nicer later. As for OpenMW not using Morrowind.ini: I am aware of it but since, like you stated, OpenMW currently does not support plugins it doesn't matter for now. Also, it's quite easy to get the whole thing to write to openmw.cfg instead of Morrowind.ini.

It is maybe a little early but hey: I'm just a novice programmer with not enough knowledge to help with the engine, but willing to do something.
What you do with it is entirely up to you, it's not like you're depending on it or something.

Zini wrote:

What you do with it is entirely up to you, it's not like you're depending on it or something.

That is certainly correct. While I think it is inefficient to develop something, of which we already know we must change it and which we are not obliged to model after the original, there is nothing that stops us from using it your work least as a placeholder until the real launcher is ready (and possibly using it also as a base for the real launcher too). Since you seem determined to do it, I'll write you up for the task.

pvdk wrote:

Zini wrote:

...there is nothing that stops us from using it your work least as a placeholder until the real launcher is ready (and possibly using it also as a base for the real launcher too).

Thanks Zini. Fact is that it's quite easy to change the layout of the dialog with Qt without rewriting the whole thing. When I'm at that stage I just need some input on how we want it to look. I have some ideas of myself I'll put up here in the form of mockups and then we can decide what's the most useable interface. Maybe even do some usability testing etc.

Star-Demon wrote:
Looks nice?

Also - this one should be able to sort load order easier.

EDIT - forgot QT.

pvdk wrote:
Some progress:

You can filter by name, sort the columns, reset to defaults etc.
Tell me what you think.

Regards,
pvdk.

ap0 wrote:
Pretty nice !
What about the loading order of the plugins ?

pvdk wrote:

ap0 wrote:Pretty nice !
What about the loading order of the plugins ?

Well currently it sorts the list of filenames alphabetically before writing them out, with the master files as first entries. Is the sort order important?

pogzy wrote:
Hi,

Nice work, even if it not usable now. It could be useful to iterate on GUI of such tool. You coudl for example, when selecting a mod, show the ones that depands from it in a certain colour, and other one which need it in another colour, or perhaps do a sort of visual tree of mod dependency on the side.

Find any other way to show with easyness in mind difficult things concerning mods, such as compatibility.

pvdk wrote:
Thanks pogzy. I like the idea of somehow visualizing plugin relationships somehow. We could extend the loader to show more file information, or even compare modified files so you can tell which files will conflict with eachother. But that stuff is planned for later, first I want to finish a OGRE settings dialog.

pvdk wrote:
A little update on the launcher. After being otherwise occupied for a couple of weeks I finally found some time to work on the launcher again. It's coming along quite nicely. I noticed it's no longer on the Roadmap for the 0.10.0 release so I still have some time left to work on it.

What's done:
- Launcher launches OpenMW ( )
- Settings dialog partially done: reads available values from Ogre but doesn't read/write settings yet.
- Data Files dialog: haven't worked on that since the last update, as OpenMW currently doesn't support plugins. So basically it's a dialog you can play with

And currently it looks like this:

Please cut me some slack on the OpenMW logo on the launcher as I'm not a graphics guy. I'm sure there's someone around who can do a better job.

Regards,
pvdk.

chewit wrote:
Looks brilliant!

Ace (SWE) wrote:

pvdk wrote:*images*

Not to nitpick, but 50 million updates per second is a bit much for screens.
50Hz would be closer to the truth.
An option for setting your data directory in settings could be useful, and you could perhaps also add a button for taking the user to this webpage.

Apart from that piece of nitpicking it's quite good though.

pvdk wrote:

Ace (SWE) wrote:Not to nitpick, but 50 million updates per second is a bit much for screens.
50Hz would be closer to the truth.

Those values are read from Ogre, so there's not much I can do about it.

First, I added the task to the current roadmap again. Considering the amount of progress you make, we can even hope, that the launcher will be finished for 0.11.0.

Second, please put your work into the openmw repository (I suggest apps/launcher/). Make a feature branch for it and then push it to github so we all can see your work. Please make sure, that the launcher is properly integrated into our cmake build system.

The current master/plugin-situation is actually not a problem. I can modify openmw in a way, that it can handle master and plugin settings in openmw.cfg. It would still ignore all plugins and all but the first master, but that doesn't affect the launcher.

What I don't like is the overall structure of the launcher. You are about to repeat the same usability mistakes, that were made with the original launcher.

I suggest only a single tabbed window.

1. Tab: Play

This should only contain a single big PLAY button, a logo and maybe the name of the current profile (more about profiles later).

N.B.: The logo is nice. Can we create a suitable logo for the wiki based on it?

2. Tab: Render Settings

Basically the current Ogre settings window.

3. Tab: Masters/Plugins

Two separate lists. One listing all master files. And one listing all plugins, that can be used for the selected master files. These must be sortable (drag and drop), since the load order can be important.
I suggest to have only one column (no file type column). Also, I suggest removing the various info widgets. These only serve to make the window more cluttered. Maybe we can have the information as a popup tooltip instead?

4. Tab: Profiles

Most MW user will have a list of plugins, that they are using with Morrowind.esm. Lets assume there is a 2nd masterfile installed (Redemption.esm). If the player wants to switch from Morrowind.esm to Redemption.esm and then back to Morrowind.esm, he has to manually select which plugins he wants again.
Therefore I propose to introduce profiles: A list of esms and esps with a handy name and optionally a comment field. The user should be able to make a new profile, based on what is selected in the 3rd tab. He should also be able to delete, edit and rename profiles.

The interaction between the 3rd and the 4th tab probably need a bit more thought.

pvdk wrote:
The launcher is currently integrated into the CMake build system of OpenMW. The folder I use is coincidentally apps/launcher, just like you suggested. I will push the progress I made to my github repository in a couple of minutes. Please note that the graphics settings currently only works for OpenGL, Direct3D will be done as soon as I get my virtual machine with Windows up-to-date. I haven't pushed my code earlier because I'm a little shy about my programming skills.

I really like your ideas for the launcher though, will definitely do something with it. A "tabbed" interface like Firefox's preferences dialog would be nice in my opinion, with icons and text instead of text-only tabs.

I think we can combine the whole plugins/profiles idea into one tab, for example: a combobox to select a profile and a frame with the included plugins. In a way not unlike playlists in a media player. Maybe savegames can be of use here later.

Well, enough ideas for now.

About the logo: I mailed the creator of the moon & stars icon months ago to ask him permission. Haven't got a response yet so I don't know if we can use it for the wiki. Apart from that: tell me the requirements for the wiki logo and I can make a better image for you, this was just a quick job.

There are quite a few things commented-out in the code, as I'm not entirely used to using git for that. Also, the header files still end with .h instead of .hpp.

Zini wrote:

I really like your ideas for the launcher though, will definitely do something with it. A "tabbed" interface like Firefox's preferences dialog would be nice in my opinion, with icons and text instead of text-only tabs.

That would be even better, if you can come up with suitable icons. Maybe try a vertical tab layout?

I think we can combine the whole plugins/profiles idea into one tab, for example: a combobox to select a profile and a frame with the included plugins. In a way not unlike playlists in a media player. Maybe savegames can be of use here later.

Might work, if you can get the profile management part in (renaming, deleting) without the whole tab becoming cluttered.
I don't think savegames are useful here.

About the logo: I mailed the creator of the moon & stars icon months ago to ask him permission. Haven't got a response yet so I don't know if we can use it for the wiki. Apart from that: tell me the requirements for the wiki logo and I can make a better image for you, this was just a quick job.

If we don't have the permission to use it for the wiki, then we probably don't have the permission to use it for the launcher. Sad!
Don't know about the requirements for the wiki logo. Size and dimensions, I guess. Maybe someone else here has more knowledge about this area.

There seems to be a problem with the openmw.cfg file through. Currently OpenMW is checking for two locations, neither one identical with the one the openmw.cfg is placed at by the cmake script. We will have to review the situation before the next release. This is also important for the launcher, because it needs to know where to find the openmw.cfg file.

btw. I think in the long run we should integrate the ogre.cfg file into the openmw.cfg file.

Object::connect: No such signal QFileSystemModel::directoryLoaded(const QString &) in /home/marc/OpenMW/openmw/apps/launcher/datafilesdialog.cpp:121

2. The master/plugin selection list is empty.

Will look at the warning, seems it causes the master/plugin selection list to be empty. Do you have the Data Files (data) directory set-up?

-Edit: What version of Qt are you using? The directoryLoaded signal was introduced in Qt 4.7 so maybe that's the problem.

Zini wrote:
Not really. See my comments above about the openmw.cfg mess-up. But the launcher should handle an empty data directory gracefully anyway.

Zini wrote:
Qt 4.6.2, which is the one from the Ubuntu repository (10.04 LTS). I don't think we should require anything more up to date.

pvdk wrote:

Zini wrote:btw. I think in the long run we should integrate the ogre.cfg file into the openmw.cfg file.

I still have to figure out a way to get the path to the ogre.cfg file in a platform-independent way. There's no setFileName() function in QSettings. If I use QSettings::NativeFormat the resulting filename is ogre.conf, if I use QSettings::IniFormat the filename is ogre.ini, so that's not an option.

Maybe I could use the getPath() function OpenMW uses?

Changing the way the settings are written, ie. save Ogre settings to openmw.cfg shouldn't be that difficult though. I will change the way the plugins are saved, the code is commented out right now.

About the empty data directory bug: I shall see if there's another signal which does the same and is available in Qt < 4.7.

Zini wrote:

Maybe I could use the getPath() function OpenMW uses?

Makes sense, but we should in general try to move these shared functionalities out of apps/openmw/ and into components/.

Zini wrote:
To expand a bit on my previous statement: I think the launcher should look for the local openmw.cfg file. If it does not exist, it should load the global one and save in the location of the local one.

pvdk wrote:
Ok, I removed the directoryLoaded() signal, but I couldn't find a signal to replace it, so It's just a dirty fix. (Function gets called once, directly, in the constructor.) As a result of this the colums don't get resized to fit their contents, so you will have to do that manually.

I didn't add a warning message for the data directory missing, as I don't want to spend too much time on this code. I believe with the new ideas for the Data Files section in our launcher the code will get overhauled anyway.
I think I won't even re-use the DataFilesModel, because for our purpose a simple QDir will do. QFileSystemModel is quite slow too, as it loads the complete filesystem before changing the root to data.

pvdk wrote:
About the plugin files: What's the name of the section the plugin files get stored under, ie: [DataFiles]?

Zini wrote:
openmw.cfg usually does not have sections.

pvdk wrote:
Well that's ok I guess but if you want to put the Ogre config into openmw.cfg you will end up with a combination of sections/no sections. Also, sections make the config file easier to parse.

Zini wrote:
I don't think boost program options does support sections. And no, we would not end up with a mix of section and non-section config file. Integrating ogre.cfg into openmw.cfg would mean defining new command line switches (which can be replicated in the openmw.cfg) for the settings currently stored in ogre.cfg.

pvdk wrote:
So no sections ok.
The command-line options sounds like alot of hassle to me to be honest. Wouldn't it be easier to keep the files separate then?
I mean, if the render system supports some fancy new feature we would have to edit not only the settings dialog, the write function but also OpenMW itself to support a new command-line switch.

Edit: fancy feature instead of version

Zini wrote:
Hmmm ... OGRE renderer are plugable. While I don't think that new renderer(s) will be of much use for OpenMW, we should keep the system as flexible as possible. Alright. Scrap the idea of merging ogre.cfg into openmw.cfg.

I don't know if Boost supports spaces in the section name. The original Ini-format specification does not. Qt converts spaces in section names to %20 when it writes config files because of this. Reading however is no problem with spaces.
We'll have to take this into account we were to use section names (which I prefer.)

Another argument for using sections is configurability by the end-user, things are explained easier on the wiki etc. if the user knows where to look.

Zini wrote:
Didn't know that. But not too excited about it anyway. I assume this would translate directly into command line arguments (haven't tried it myself). That would be awkward to use, at least for ./openmw. You can use launcher-specific sections though (let's say for the profiles).

pvdk wrote:
I'm not sure what you mean with command-line options but this is what I found, it's called Property Tree and it can be used with Ini-files.
Look here: Boost Property Tree documentation
I'm not familiar with Boost and the way OpenMW reads the config file so I hope this makes sense.

As for the profiles. Shall we store them in separate files or inside the openmw.cfg? maybe like this?

[Profile/Player1]
master=Morrowind.esm
plugin=MyPlugin.esp

Zini wrote:
We are using a unified system. Every entry, that appears in the cfg file, can also be used as a command line switch (i.e. master=Morrowind,esm in the cfg file, --master=Morrowind.esm in the command line). This is an very useful feature and I really don't want to abandon it by splitting off the cfg file reading from boost program options.

Using the openmw.cfg file for profiles is okay.

pvdk wrote:
Ah now I see what the problem is. The whole thing being unified is indeed something to keep. And you're right about the command-line arguments needing the sections, the format for this would be, if the section is General:
--General.data=/opt/openmw/data

Not pretty at all

My Data Files writeConfig is done, will push it in a couple of minutes. It's just a proof-of-concept right now, and it writes the config to the current directory. Have a look

Oh and the data directory problem should be "solved" too, the path it looked for was /opt/openmw/data. Now it's just ./data, but in the future it should read from the config file (or get it from components/path).

Update: pushed.

Zini wrote:
Yeah, it works.

Now it's just ./data, but in the future it should read from the config file (or get it from components/path).

Actually it should get it from the openmw.cfg files. But its needs to get the location of the openmw.cfg file from a future path component.

pvdk wrote:
Ah yeah got the two mixed-up. Glad it works.

pvdk wrote:
I made a little mockup of how I think the Data Files section should look like:

Basically all the plugins go in the treeview left, with their masters as parent nodes, so you would have something like:

These can be dragged and dropped in the tableview on the right. Master files (which are not in the mockup) should appear on top. If you drag a plugin whose master files are not yet on the list then they should be added too. The elements in the tableview can be moved around using the buttons below or by dragging/dropping them. The elements can be numbered.

Well, whaddayathink?

Zini wrote:
Sorry, not going to work. A plugin can depend on multiple masters, i.e. the plugin is only available if all those masters are selected. But a plugin can be used even if additional masters are selected. With your design you would need to list any combination of compatible masters, with plugins appearing multiple times in different parts of the trees.
Also, there is currently no way to determine which masters are compatible, so you would need to list all combinations of masters.

I don't think there is an alternative to having one list for the masters and a 2nd dynamic list for the plugins.

Also, with these two lists, the interface will look very cluttered (for my taste even your current design looks slightly overloaded).

I suggest the following changes:

- split the plugin list in two (2nd list adjusted dynamically when 1st list is changed)
- make both lists sortable by drag and drop
- drop the list on the right side of the window (there is little point in having a separate list, if the function can be integrated into the primary lists)
- drop the icons and the tree view. Don't add a checkbox either (like in the original launcher). Just make the lines in both lists selectable (multiple selections obviously)

Edit: Since this is not a dialogue type window, all the changes should apply instantly. We don't need an OK or Cancel button. For the same reason, we don't need a save button. The openmw.cfg file can be saved, when the launcher is exited (either by closing the window or pressing play).

pvdk wrote:
Yeah I forgot about the multiple masters, stupid

I don't think the two-table model you propose has to be all too cluttered, as the masters table doesn't have to be that big. (People don't have 100s of master files)

Another problem however, how do you want to include profiles in this design? I really like the idea of having the plugin selector and the profiles in one page, for obvious usability reasons.

The Ok and Cancel buttons are just the default buttons you get in Qt's designer. I agree with you that they should be different, but this is only a mockup.

Zini wrote:

(People don't have 100s of master files)

I have around 15

If we have master right and plugins left, they should be equally big (or nearly so). If we have them one above the other, can we make the divider movable? i.e. the user can decide how much space he wants to allocate to master and plugins. In Gtkmm, that would be a VPaned widget. No idea, what it is called in Qt.

Another problem however, how do you want to include profiles in this design? I really like the idea of having the plugin selector and the profiles in one page, for obvious usability reasons.

I agree. But actually I don't see a problem. You can have a simple profile selection combobox (just as in your current design). The changes in the master and plugin list would always affect the currently selected profile.

pvdk wrote:
Yeah a selector is just what I was thinking about. It is possible with Qt too, don't know what it's called though.

So, to get this straight: for every selected master file the plugins that depend on it get added to the list. Selected plugins get saved to the current selected profile when the user presses the "Play" button on the start page. (which should be below each page too I suppose)

Well I think we can manage this, no problem indeed as we actually don't need all the buttons.

Zini wrote:

for every selected master file the plugins that depend on it get added to the list.

I'll rephrase. Every plugin has a list of master files. If this list is a subset of the selected master files, the plugin is added to the list of available plugins.

Selected plugins get saved to the current selected profile when the user presses the "Play" button on the start page. (which should be below each page too I suppose)

Since we are doing this with the instant-change paradigm the data should be saved whenever the launcher is exited (either by pressing play or by closing the window).

On these events you have to update the openmw.cfg file with the following:
- all modified profiles (this is only for the launcher, ignored by openmw)
- the name of the currently selected profile (this is only for the launcher, ignored by openmw)
- the plugins and masters in the currently selected profile. These go into master= and plugin= and this is how OpenMW gets its configuration.

Be basically keep the configuration for launcher and OpenMW separated.

pvdk wrote:
That's exactly how I had it in mind, good.

What do you think of this?

Note that just as in the other mockup the contents in the views are just copypasta, so that's why it looks a bit off. Also, there's a resize thingie in Qt and it's called QSplitter. It is not available in Qt Designer though so you'll have to imagine there being some dots inbetween the views and the bar being a bit thinner.

Zini wrote:
Mostly good. What is the widget at the top of the window for?

Also, you will need some buttons for profile management:

- add profile: adds an empty profile
- copy profile: creates a copy of the current one with a new name
- delete profile: deletes the currently selected profile; inactive, if there is only one profile left.

pvdk wrote:

Zini wrote:Mostly good. What is the widget at the top of the window for?

That's the container for the icons with the various config sections, like for instance the Graphics. I like a horizontal bar better than a vertical one.

Apart from the add, copy and delete I would like a button to deselect all plugins.
Also, is it a good idea to save the profile if the user presses Close? As a user I would expect it wouldn't if I screwed something up.

Zini wrote:

That's the container for the icons with the various config sections, like for instance the Graphics. I like a horizontal bar better than a vertical one.

Okay.

Apart from the add, copy and delete I would like a button to deselect all plugins.

Makes sense.

Also, is it a good idea to save the profile if the user presses Close? As a user I would expect it wouldn't if I screwed something up.

We agree to not have a close button in the window. So I assume you mean the close button in the window title bar? Me, as a user I would expect it would keep the changes. That is the whole point of the instant-change paradigm. We skip the whole save/okay/accept stage.

Actually, I would find it quite strange, if clicking the close button would discard all changes. And I would be a bit pissed off maybe, because as a user I might decide to change the configuration now, but play later. Finding later that my configuration changes have been discarded, would not be nice.

pvdk wrote:
Are you by any chance a Gnome user?

I can see were you're coming from and I'm okay with it, but not having a close button at the bottom of the config dialog would be a mistake in my opinion.
You see, the whole thing is not a set of separate dialogs right now so if you press close the whole launcher exits, (Maybe call it exit instead of close then )

The buttons stay the same for each page, as the config sections are pages stacked on top of eachother, like this:

[Frame with icons for each section]
[QStackedWidget with all the config pages]
[QDialogButtonbox with Play and Close or Exit]

Zini wrote:
Yes, I am a Gnome user

Well, if you really want to go for the buttons, then we must make some changes.

First it must be clear, that these buttons are not part of the tabs. I think just making them the same on each tab is not enough. the distinction between the content area and the button area should be made clear.
If it looks like the buttons are part of the content area, the user might wonder, if this only affects the current tab or the whole thing.
Maybe put a 3D-border around the middle content area? Make it look sunken in? Sorry, I really wish, I would know the proper Qt terminology to explain that.

About the buttons:

We need at least:

Exit: Saves state
Abort: Does not save state

I am not sure, if we actually need to have a play button, since the whole purpose of the first tab is to provide a play button. But I am not strongly against it either.

Also, we should avoid having a close button in the title bar, because you could never be sure, if it means Exit or Abort. I know you can't switch it off, but under Gtkmm you can at least provide a hint, that this button should be avoided, if the window manager permit it. I assume Qt can do the same.

pvdk wrote:
Something else we could do instead of two separate buttons for Abort and Exit would be one button, say Close, and pop a warning message when the user presses it and changes are made:

The settings of the current module have changed.
Do you want to apply the changes or discard them?
[Apply] [Discard] [Cancel]

That way we can keep the x in the window bar, as I really hate to see it go. (Frustrates me to pieces if I use software which doesn't have one)

About the play button. I thought it would be nice to select your plugins, or render settings and being able to start the game directly from where you are, instead of going with the mouse to the first icon and pressing play. (Saves 1 click )

And the distinction between current tab/whole dialog: I will think about making it more obvious but I really think it's not necessary.
Or maybe we could look (again) at the KDE System Settings:

Main page (would have a play button for us and the config catagories above that):
Settings module:

It's not exactly instant-change paradigm, I know.

Zini wrote:

Something else we could do instead of two separate buttons for Abort and Exit would be one button, say Close, and pop a warning message when the user presses it and changes are made:

Don't like the idea. I think these kind of dialogues are annoying and we should use them lightly. I am okay for using it for the window title bar button, but having it on a close button in the window area is just a usability burden.

About the play button. I thought it would be nice to select your plugins, or render settings and being able to start the game directly from where you are, instead of going with the mouse to the first icon and pressing play. (Saves 1 click )

In general I do not agree with this kind of thinking. Adding a feature here and there to safe the user 1 click is one of the main reasons why we ended up with the mess we like to call user interfaces these days (it looks like we might get into more GUI discussions in the future, so I just want to make my overall position clear).
In this specific case, it is okay though. We have only a small number of buttons and enough space. So just add the run button.

I am not sure in what way those two screenshots would apply to our situation.

It's not exactly instant-change paradigm, I know.

We have already decided to abandon it entirely a few posts above, so that is okay.

pvdk wrote:
Haha no need to abandon the instant-change paradigm yet, as I'm starting to like the concept and there's not a single line of code written so far.

I had another look at the Firefox Preferences dialog, that's a GTK+ app right?
If you press close or the x in the window bar there while having made a change, the changes get saved. I think if we go with instant-change we should do the same.
I don't have many GTK+ apps around so I wasn't sure about the concept, but now that I've tried it, it makes sense (finally! ).

But you will also notice that there's no real distinction between tab contents and the dialog buttons. The close button just stays the same. And frankly I think that's enough. If we keep the buttons to a bare minimum that is, so only a Close button or a Close and a Play button.

I tried the frame you proposed, but the effect is lost if I use a GTK+ style for the launcher. GTK+ doesn't have borders around group boxes and only the sunken frame works.

Does that work for you?

sir_herrbatka wrote:
BTW: we need one extra button. Continue button that just starts game and loads most recent save.

pvdk wrote:

sir_herrbatka wrote:BTW: we need one extra button. Continue button that just starts game and loads most recent save.

Or we could make the Play button have a drop-down menu, like if you hold it some more options appear, for instance "Add command-line parameters"

Only warning I would recommend is an "Are you sure?" if the user clicks on Deselect all. That's the biggest screwup I can imagine I would make, no reason not going for instant-save if there's a warning in place.

sir_herrbatka wrote:
then let's make "continue" button dropdown with saved games (but there should be box to set it to run most recent save) and "run" button with advance options. Maybe launcher should kill openmw main menu.

pvdk wrote:
I like the idea of not having a main menu if we can get the launcher to do it all. But that's worries for later on, first I want to know how to implement the things that we need right now.

Peppe wrote:

Zini wrote:There seems to be a problem with the openmw.cfg file through. Currently OpenMW is checking for two locations, neither one identical with the one the openmw.cfg is placed at by the cmake script.

I believe the installation part of the cmake file will place it where it is expected. But running directly from the build directory requires some manual steps, the easy solution should be to just look for it in the current working directory too. Should be an easy change, I might have a look at it for the weekend if no one fixes it before that.

Zini wrote:

Haha no need to abandon the instant-change paradigm yet, as I'm starting to like the concept and there's not a single line of code written so far.

Okay. So we are in agreement, that the close button will keep the changes, right? That's what this paradigm is about after all.

I like the overall look of those two screenshots. But I think the profile button is not wide enough. Maybe we could move the Deselect All button left of the filter field, so we have more room down there? This way the bottom row would exclusively handle profile management.

Only warning I would recommend is an "Are you sure?" if the user clicks on Deselect all. That's the biggest screwup I can imagine I would make, no reason not going for instant-save if there's a warning in place.

Actually, I would see such a warning as an annoyance. Deselecting your master/plugin list isn't particular big as screwups go. But I can see your point, so lets go with it for now.
I suggest, if we add more functionality to the launcher at a (much) later point, we add a launcher settings tab, that has an option to disable this warning dialogue (not worth doing it now for only one checkbox).

I like the idea of not having a main menu if we can get the launcher to do it all

I think that goes into the wrong direction. OpenMW needs all the Main Menu functions. You can't expect the player to leave the game and return to the launcher, each time he dies and needs to reload a saved game. Same for changing settings and other main menu stuff.

Also, please keep in mind, that the launcher is an optional component. The player should be free to start OpenMW directly. There are many usage scenarios for this. One example would be a total conversion, that provides a shortcut on the desktop (assuming a Windows-style desktop), that starts OpenMW with the command line options for the required master file without going through the launcher. That would make the TC look more like a separate game.
Actually with the master/plugin settings completely configurable on the command line, I would expect some power-users to quite commonly create these kind of shortcuts for them self.

pvdk wrote:
I believe the openmw.cfg should be placed in the freedesktop.org specified config directory, ~/.config/openmw/ or /etc/xdg/openmw/ iirc. I don't know about Win or Mac.

Zini wrote:Okay. So we are in agreement, that the close button will keep the changes, right? That's what this paradigm is about after all.

Yes, closing the dialog wil keep the changes.

Zini wrote:I like the overall look of those two screenshots. But I think the profile button is not wide enough. Maybe we could move the Deselect All button left of the filter field, so we have more room down there? This way the bottom row would exclusively handle profile management.

Like the idea, makes more sense too if Deselect all means: deselect masters and plugins. The checkbox being not wide enough is just fine-tuning, I dont' bother yet to edit all this and go for the default settings.

Zini wrote:Actually, I would see such a warning as an annoyance. Deselecting your master/plugin list isn't particular big as screwups go. But I can see your point, so lets go with it for now.

Haha you bloody minimalist
Edit: thought of something: what about a checkox on the warning message: "Don't show this again?"

About the launcher replacing the main menu: you're right. (again )

Peppe wrote:

pvdk wrote:I believe the openmw.cfg should be placed in the freedesktop.org specified config directory, ~/.config/openmw/ or /etc/xdg/openmw/ iirc. I don't know about Win or Mac.

No, this is build time (or actually when you run cmake), not installation time.

Zini wrote:

I believe the installation part of the cmake file will place it where it is expected. But running directly from the build directory requires some manual steps, the easy solution should be to just look for it in the current working directory too. Should be an easy change, I might have a look at it for the weekend if no one fixes it before that.

Yes, I think you are right. It only affects running OpenMW without installing it. What you suggest makes sense. But we also need to adjust the openmw.cfg file for using it with the uninstalled game, since the resources currently point to the wrong directory (for the unistalled game).

Those causes problems for the launcher though. Where is it supposed to store the file? We would need a way to tell the launcher, that it is running on an uninstalled game.

If we can handle that somehow without to much work, that is okay.

Another option I can think of would be simply not to copy the openmw.cfg file to the build directory and add a few lines to the documentation, telling the user, that he has to add it himself, if he wants one (maybe with the typical locations, per OS).
After all, the uninstalled version of OpenMW should run just fine without a cfg file. At least it does so on Linux. We should check Windows and OS X to make sure.

Zini wrote:

he checkbox being not wide enough is just fine-tuning, I dont' bother yet to edit all this and go for the default settings.

Yeah, I did get that. I meant there isn't room enough to make it wide enough (with the Deselect button present).

Haha you bloody minimalist

Absolutely! I am a firm defender of the KISS principle and the fact, that less is more.

Edit: thought of something: what about a checkox on the warning message: "Don't show this again?"

And how do you switch it on again, if you change your mind?

Anyway, looks like we are completely in agreement now about the launcher design. Good!

pvdk wrote:

Zini wrote:And how do you switch it on again, if you change your mind?

For now a checkbox should be enough, later on we can introduce a "Launcher settings" section for the bipolar users who do things they later regret

Zini wrote:Anyway, looks like we are completely in agreement now about the launcher design. Good!

Glad we are! I'll let you know when there's some code to look at.

pvdk wrote:
Ok, I have something to show you guys.
It's a proof-of-concept of what the Data Files tab should look like. I edited the existing Data Files dialog for this but the code will be incorporated into the new launcher. It looks like this:

No master selected:
Masters selected:

The treeview is there for testing, so don't worry, it will be gone in the real thing.

Basically it works like this:

1. Plugin files are read from the data directory, now ./data. (will get the path later from openmw.cfg)
2. The masters of each plugin are read, appended individually to mastersmodel (which you use to select the masters), and combined as a comma-separated entry in the datafilesmodel (which holds the plugins and which you can see in the treeview now).
[/list:u]
The code can be seen here: datafilestest branch on github
Note that it needs some serious cleanup, commenting and renaming etc.

Zini wrote:Removed the file. Now I am getting tons of errors at compile time.

Stupid leftover files. You can remove datafilesmodel.cpp and datafilesmodel.h too as they aren't used anymore. Will test it first next time I push

Or you could wait till I get home.

pvdk wrote:
Ok, pushed to github, should work now. I also added support for sorting the plugins. Something that occurred to me then was that we cannot have the select-multiple-plugins idea we had. We'll have to use checkboxes because you can't sort manually and use multiple selections, as you would drag the whole selected list around instead of one item.

There's a context menu when you right-click on the plugins and you can doubleclick an item to make it checked. (Moving not implemented yet)

What I want to add for the sorting: when you sort an item the selection gets lost. I want to make it so that the item that gets moved keeps it's selection.

Zini wrote:
Nice!

Something that occurred to me then was that we cannot have the select-multiple-plugins idea we had. We'll have to use checkboxes because you can't sort manually and use multiple selections, as you would drag the whole selected list around instead of one item.

I guess it is not possible to move only one row, even if multiple are selected?

pvdk wrote:
Short answer: No.
Long answer: Might be possible but I've never seen it and it would require extensive subclassing and rewriting.

pvdk wrote:
Little update: began working on the new launcher, implementing the ideas we discussed.

Here's how it looks:

Still have to work on the Graphics tab so can't show that yet.

Edit: Just occurred to me: what's that "Deselect All" button doing there

Zini wrote:
Mostly good. I would widen the current profile button so far, that it covers all of the available space (no point in wasting it).

But we have a problem with the first tab. Having a regular button looks odd. Also since we already have a play button at the bottom, it is entirely redundant. I think we need to rethink the first tab. I don't have any clever ideas at the moment though.

Edit: Okay, I have one (not sure about its cleverness).

I suggest we rename the Data Files tab into Profiles tab, because its main purpose is to manage the profiles.

On the Play tab, we make the following changes:

- Remove the play button at the bottom (if there are two, the player will ask himself what the difference is). I still kinda think it would be better for consistency to remove it from all tabs. Consistency > small amounts of usability/comfort.
- Widen the main play button. Maybe replace it with something more fancy (graphical?)
- Below the play button add a copy of the profile button from the Profile tab (but label it profile instead of current profile). These must be kept in sync width the profile button on the profile tab (both always showing the same profile).

This way the Profile tab would mostly serve to configure profiles, while you would normally choose a pre-existing profile from the play tab.

pvdk wrote:
Zini, that's exactly what I had in mind The profile button is a combobox but with nothing in it right now so that's why it's grey.

I want to improve the play button with a delayed popup menu (like your browser's back button.) An option we could add is "add command-line parameters" but I'm sure you can think of more. (I hope so because else the popup menu is a bad idea I think)
I will think about the look of the button.

About the play button at the bottom of each tab: I wanted to remove it from the Play tab, just like you suggested, but I really want to keep it on the other tabs. I strongly believe usability > consistency here.

Oh and there are some things we have to fine-tune with the Profile/Data Files tab, such as the plugins table. I want to make the row size smaller so more plugins fit in the table without scrolling. Another thing I tried was masters table below plugins table, but I'll show you an example of that.

sir_herrbatka wrote:
popup menu suxxxxxxx.

Ok, popup menus are cool but why not just add edit field below play button (and continue button above play button as it's must have feature).

Continue from the last saved game

Start the game
Use parameters [checkbox]
Edit field that is visable after setting checkbox above to "on"

Zini wrote:

I want to improve the play button with a delayed popup menu (like your browser's back button.) An option we could add is "add command-line parameters" but I'm sure you can think of more. (I hope so because else the popup menu is a bad idea I think)

Not really. Even additional command-line parameters are mostly pointless. The master/plugin settings are the only aspect of the cfg file, that a regular user should need to change. Everything else is highly technical and probably appeals only to a public, that is more comfortable with using the cfg file or the command line directly. Most of the current options are development/debugging-related anyway and quite a few of them will be dropped before we reach 1.0.0.

pvdk wrote:
Yeah forgetaboutit then

Edit: by popup menu I meant a popup that pops up under the button, not a separate dialog.

pvdk wrote:
Here are some alternative ways we can present the plugins/masters:

Added bonus would be that we could include some toolbuttons above the pluginview with move up/down etc. I personally like the first with the horzontal layout of the views.

Oh and I'm not entirely sure about the combobox being stretched all the way.

Zini wrote:
I agree. The horizontal layout looks better.

But

Added bonus would be that we could include some toolbuttons above the pluginview with move up/down etc.

please, don't! We have such a nice clean design. It would be a shame to clutter it with additional buttons.

Oh and I'm not entirely sure about the combobox being stretched all the way.

Who knows how long users will make their profile names? Pretty long probably. We should give them as much space as we can.

pvdk wrote:

Zini wrote:please, don't! We have such a nice clean design. It would be a shame to clutter it with additional buttons.

Haha no I won't

Zini wrote:Who knows how long users will make their profile names? Pretty long probably. We should give them as much space as we can.

Yeah, about that: Should we support spaces in profile names? The original Ini format specification does not and I want to use the profile name as [Catagory]. It can be done however, either with %20 or by writing my custom settings write method instead of using QSettings.
Your call.

Chris wrote:
Not sure I like how ESMs and ESPs are split like that. AFAIK, the only real difference is the engine will load ESMs first, then ESPs. That is mostly because of the file-date-as-load-order the original game used, to make sure masters are loaded before patches. However, people have also found (and regularly use) ways to make an ESP use another ESP as a master (to patch a patch), and OpenMW doesn't use the file dates to determine load order, so I don't think just a plain ESM-before-ESP rule should be the way to go.

Personally, I like the way Wrye Bash does the selection list:

There's a check box to the left of the ESM/ESP, and clicking an entry would list its info on the side of the dialog. ESMs are color-coded lightblue, ESPs have a green check box. Files with problems (but are still usable) have an orange checkbox, and unusable files (eg, those with missing masters) have a red checkbox. OpenMW's launcher could forcibly reorder the list to make sure files that are used as masters come before the files that use them, with ESMs always first if you like, but otherwise, I see no reason to have such a hard separation between ESMs and ESPs.

pvdk wrote:
Thanks for your input Chris. Well the idea now is that when you select a master the plugins which depend on it get loaded into the plugin view. (You don't see the plugins until you select one or more masters.)

I like the idea of various colors depending on the state (check for conflicts etc.) Something to think about later. Is Wrye Bash's source available?

Chris wrote:

pvdk wrote:Thanks for your input Chris. Well the idea now is that when you select a master the plugins which depend on it get loaded into the plugin view. (You don't see the plugins until you select one or more masters.)

Yeah, I think that would put restrictions on ESPs-as-masters, or at least cause unnecessary behavior differences for them. I think having ESMs and ESPs all in one view, color-coding them as needed, and automatically selecting the masters of a particular plugin you enable (with an alert box if something is being forced on that's not already selected), would be the way to go.

I like the idea of various colors depending on the state (check for conflicts etc.) Something to think about later. Is Wrye Bash's source available?

Yeah, about that: Should we support spaces in profile names? The original Ini format specification does not and I want to use the profile name as [Catagory]. It can be done however, either with %20 or by writing my custom settings write method instead of using QSettings.
Your call.

Sounds like a lot of additional work. I would be perfectly content without spaces.

However, people have also found (and regularly use) ways to make an ESP use another ESP as a master (to patch a patch), and OpenMW doesn't use the file dates to determine load order, so I don't think just a plain ESM-before-ESP rule should be the way to go.

I don't know what you mean here. If you mean making an ESP modify records defined in another ESP, this is supported by our current design. You just have to adjust the load-order.

The purpose of the split is mainly to not have Plugins for completely different sets of masters mixed up (let's say Morrowind/Tribunal/Bloodmoon on one side and a TC like Redemption on the other). Splitting the Masters from the Plugins is a must to keep order.

btw. we actually need to use date-based load-order for the masters to make sure Morrowind, Tribunal and Bloodmoon are loaded in the right order.

Chris wrote:

Zini wrote:

Yeah, about that: Should we support spaces in profile names? The original Ini format specification does not and I want to use the profile name as [Catagory]. It can be done however, either with %20 or by writing my custom settings write method instead of using QSettings.
Your call.

Sounds like a lot of additional work. I would be perfectly content without spaces.

I think spaces would be pretty important. If "encoding" them (eg, turning a space into %20 for the section name) isn't hard, I think that would be best. Otherwise, you could add a display name option to the section which is used for display (though that can get confusing if multiple sections have the same display name). Specifying a TC's name as the profile name, or a character name as a profile name, would all but require spaces and special characters, and users may not like such a restriction.

The purpose of the split is mainly to not have Plugins for completely different sets of masters mixed up (let's say Morrowind/Tribunal/Bloodmoon on one side and a TC like Redemption on the other). Splitting the Masters from the Plugins is a must to keep order.

Wouldn't a better idea be to give each TC its own folder, and letting a profile specify an alternate data folder? Eg, have a default data folder specified in the config, then allowing a profile section to specify an alternate data folder. You'd then use a different profile with an alternate data path to set up a game with the TC.

btw. we actually need to use date-based load-order for the masters to make sure Morrowind, Tribunal and Bloodmoon are loaded in the right order.

The proper order can be derived from dependency requirements. I don't see a problem with a new profile creating an initial list that's sorted by date, and maybe even have a button to re-sort the load order according to file dates... but I don't see a reason to force that in the engine. Start with a date-sorted order, but let the user change it as they want without messing up the file dates.

Date-based loading order feels more like a remnent of the game's development, where you have changes in an ESP that you work on and test, that then get "committed" to the ESM when finished -- scenerios like that would be best served by using file dates because the newest stuff always supercedes the older. But for a proper modder-friendly engine, using the order they're specified in as the order to load would be many times better. Sometimes older mods have to be loaded after newer mods to function properly, and vice versa, so they have to be re-ordered to fix such conflicts. It would be nice to not have to play around with the file's date to do that, because you're then changing what the file's date is meant to represent -- was that ESP really last modified on Dec 16, or was it just set there to force a loard order? etc, etc..

Zini wrote:

Wouldn't a better idea be to give each TC its own folder, and letting a profile specify an alternate data folder? Eg, have a default data folder specified in the config, then allowing a profile section to specify an alternate data folder. You'd then use a different profile with an alternate data path to set up a game with the TC.

That would be a reasonable way to do it. But that is not how it is done currently with MW (because it is not possible). We can't expect everyone who makes content for MW to reorder their directory structure.

The proper order can be derived from dependency requirements.

If you talking about ESMs here, as far as I can see the answer is no. At least from what I see in the available ESM documentation that is not possible.

Date-based loading order feels more like a remnent of the game's development, where you have changes in an ESP that you work on and test, that then get "committed" to the ESM when finished -- scenerios like that would be best served by using file dates because the newest stuff always supercedes the older. But for a proper modder-friendly engine, using the order they're specified in as the order to load would be many times better. Sometimes older mods have to be loaded after newer mods to function properly, and vice versa, so they have to be re-ordered to fix such conflicts. It would be nice to not have to play around with the file's date to do that, because you're then changing what the file's date is meant to represent -- was that ESP really last modified on Dec 16, or was it just set there to force a loard order? etc, etc..

We are talking about ESMs here, not ESPs. As mentioned above the load order of ESPs can be freely adjusted by the user.

Chris wrote:

Zini wrote:That would be a reasonable way to do it. But that is not how it is done currently with MW (because it is not possible). We can't expect everyone who makes content for MW to reorder their directory structure.

Modders wouldn't need to change anything. All it would be is, the user extracts the TC somewhere else other than next to Morrowind.esm, and creates a new profile to point there for data instead of the default place. Then make sure the ESMs and ESPs are enabled in that new profile, and click Play.

Deinstallation is then as easy as trashing that alternate data directory and deleting the profile.

If you talking about ESMs here, as far as I can see the answer is no. At least from what I see in the available ESM documentation that is not possible.

I'm not sure how not. ESMs list their dependencies... Tribunal and Bloodmoon both have Morrowind.esm as a dependency. IIRC from my modding days, ESMs were actually more restricted in what data they could modify from their masters, and (just like ESPs) can't modify something they don't have as a master. So the two possible load orders:

should have the same result, since Tribunal and Bloodmoon only make changes to Morrowind.esm and not each other. The only problem I could see is if they both change the same thing in Morrowind.esm and each do it differently, but that doesn't seem likely.

Zini wrote:

I'm not sure how not. ESMs list their dependencies

The ESM/ESP documentation on UESP says otherwise. But I just checked it myself and there is indeed a MAST sub-record in the later ESMs. Seems the documentation is wrong.

This simplifies things slightly. I guess OpenMW should just check these dependencies and then sort the ESMs accordingly (to handle the case where two ESMs actually modify the same record). If we had a Morrowind-Tribunal-Bloodmoon-scenario and Bloodmoon would modify Tribunal, we can assume that Bloodmoon would specify Tribunal as dependency (this is just an example).

Actually it would be easier if the Launcher did this kind of sorting and OpenMW would accept the given load order as correct without checking.

The fundamental idea here is still that ESMs describe the original game and are all provided by the original vendor (e.g. Bethesda for Morrowind) and as such won't require any kind of load-order tweaking.

pvdk wrote:
Could indeed be handled by the launcher, I will look into it.

pvdk wrote:
Hi guys,

Would something like this work, granted that it's done by a proper graphics designer guy instead of me?

PS: We need a graphics designer guy

sir_herrbatka wrote:
I would prefer to stick with plain and simple, clean qt look.

Zini wrote:
I think for the play tab it works nicely, but we should keep the other tabs conventional.

pvdk wrote:
I agree, that's the plan.

Greendogo wrote:
I'm glad you decided to liven up the launcher with some themed graphics.

I agree, we do need a graphics guy. Maybe just make it easy to skin the launcher and modders will do the work for you.

pvdk wrote:
Oh the skinning is really simple, Qt uses CSS stylesheets so everyone with some CSS knowledge can skin the launcher. And you don't have to recompile the launcher to change the stylesheet, useful for non-coders.

Zini wrote:
Any progress on the launcher?

btw. I tried your newlauncher branch. Doesn't build. The CMakeLists file contains traces of an unresolved merge conflict and also there seems to be trouble with some (missing?) files again.

make[2]: *** No rule to make target `/home/marc/OpenMW/openmw/apps/launcher/resources/openmw-icon.png', needed by `apps/launcher/qrc_resources.cxx'. Stop.

pvdk wrote:
Yeah had some troubles pushing my branch to github, will sort it out. No progress in code but I thought about some stuff:
I think I should go with a separate config file for the launcher in which I store the profiles. When the launcher grows more complex we'll need a separate config anyway and that way I can use QSettings instead of my own method (and be sure the launcher does not screw up the openmw config.)

The exams are over now so expect to see some progress next week or so, I will implement the stylesheet for the Play tab and start working on the Graphics tab.

Regards,
pvdk.

Zini wrote:

I think I should go with a separate config file for the launcher in which I store the profiles. When the launcher grows more complex we'll need a separate config anyway and that way I can use QSettings instead of my own method (and be sure the launcher does not screw up the openmw config.)

That is okay. Just make sure you place your config file at the right location (alongside the user openmw.cfg file).

pvdk wrote:
Right, the OpenMW icon was missing because I renamed it and I was pushing the wrong local branch, which doesn't exist on github (git doesn't issue a warning when you do that )
It should build now. Haven't implemented the stylesheet yet but the Combobox works on the Play tab.

Edit: Added stylesheet support to the launcher, it's not perfect yet but have a look. Currently the centering of the items inside the scroll is not perfect and the items ignore the padding of their parent. Oh and the combobox popup sucks and won't listen to me.

Whilst committing I found out not to use -f when doing git rm with wildcards, it is recursive Almost lost all of my edits but luckly my editor creates backup files.

Zini wrote:
I noticed a problem with your newlauncher branch. You are modifying apps/esmtool/Makefile. Probably not on purpose. These changes look like the original Makefile has been overwritten by something created by cmake.

An out-of-source build could have avoided this problem. Also, you should always do a git status before a commit.

pvdk wrote:
Ah crap, you're right. I tend to do a git status before I commit, must have missed it. That's what happens when you're coding when you should be sleeping I guess. You're right about the out-of-source build too. I accidentally started coding in my build directory and was too lazy to switch dirs, thinking it wouldn't matter

Zini wrote:
Your fix still don't restore the original makefile. But okay, I guess nobody was using it anyway.

Your more recent commits look strange. Was that a rebase? I am not an expert on this git feature, but AFAIK you should never rebase anything, that is present in a different repository. Rebase is really only for unpublished stuff, that hasn't been used by anyone else yet.

pvdk wrote:
Yeah it was a rebase. I thought it did what I wanted to do but yeah: never rebase How's it looking now though? I tried to fix it best I could but rebasing seems to screw up alot.

Do you think it'll work or should I create a new branch from scratch. I'm working on the config branch right now.

Zini wrote:
I don't see a difference compared to before. Actually I don't see any new activity from you on github at all.

I suggest you delete the config branch, merge in my config branch into your newlauncher branch and continue from there.

pvdk wrote:
My local branch is ahead of the github repository with 2 commits but what do you mean with no activity? I've pushed quite some commits.

Also, as you can see there are a lot of duplicate commits because of the reverting. Is there any way I can go back to the commit before the rebasing and just continue from there?

What's the best way to do the things you propose, that is, merging my newlauncher with config and continue from there?

Oh and something else: How should I include path.hpp in the CMakeLists.txt, or should I wait when it gets moved to components or so.

Thanks for the help with git, really appreciate it.

Zini wrote:
There was no activity from you on github for 8 hours. I can't see what you did to fix the original problem, therefore I can't give you any advice on it.

What's the best way to do the things you propose, that is, merging my newlauncher with config and continue from there?

Oh and something else: How should I include path.hpp in the CMakeLists.txt, or should I wait when it gets moved to components or so.

I suggest moving path.hpp/path.cpp to a new component (file) now and adjust the code and the cmake scripts accordingly. Later we might move the whole openmw.cfg file locating to this component too, since we need it in the launcher, in openmw and the editor.

pvdk wrote:
Ok, the newlauncher branch is fixed, no more apps/esmtool/Makefile changes/deletion anymore.

Note: will do the config branch with the latest code tomorrow or so

Peppe wrote:

pvdk wrote:Also, as you can see there are a lot of duplicate commits because of the reverting. Is there any way I can go back to the commit before the rebasing and just continue from there?

You can use reset to move your branch pointer to a previous commit.
To just throw away the last commit (and changes in tracked files in the working tree) do
git reset --hard HEAD~1

Note that if this is on a branch you have pushed an someone else have started working on something on top of it, this will require some work to clean up.

pvdk wrote:
Thanks for the tip Peppe. I had alot of dupicates somehow but I did a rebase and removed the changes to the Makefile.

Zini wrote:
May I ask what the current state of the Launcher is, i.e. what remains to be done?

I think the graphics tab isn't working properly yet. The close button doesn't work. And we need to do some cleanup regarding the openmw.cfg location (move the code to a component). Is that all or am I missing anything?

pvdk wrote:
1. Close button is working on the branch which I need to cleanup/merge and re-push to Github.
2. Graphics tab is currently not there, but I'll start working on it as soon as the Data Files tab is done.
3. The config location is indeed not yet in a component. I'd rather see it moved to a non-OpenMW-specific location but I guess I could do the thing you suggested: copy the path.cpp/hpp files. (really ugly with #include "../openmw/path.hpp" now)
4. The most important thing for the launcher still isn't there: launching the game Shouldn't be too hard. One thing we have to decide is if the launcher quits when the game is launched or if it stays there. I briefly got into launching the game with the previous version of the launcher and I could not get the application to quit without losing it's child process (the game). It is possible but I need to look into it.

What I'm working on right now: Loading the launcher.cfg which holds the profiles and automatically select them. The launcher now saves the profiles to the launcher.cfg as soon as the user switches profiles with the combobox or when he presses the close button. It also loads the new selected profile and checks the plugins/masters which are specified by it.

What I will be working on next: Making it possible to create new profiles and figure out the sorting/moving items up/down. Something I want but which I could'nt get working is when a plugin gets moved that it stays selected so you can see where it got moved.

Zini wrote:

3. The config location is indeed not yet in a component. I'd rather see it moved to a non-OpenMW-specific location but I guess I could do the thing you suggested: copy the path.cpp/hpp files. (really ugly with #include "../openmw/path.hpp" now)

Don't copy. Move. Is your grasp on cmake scripts firm enough to handle it? If not, I can do the move for you. I am working on the config stuff anyway.

One thing we have to decide is if the launcher quits when the game is launched or if it stays there.

The launcher should definitely not continue to run, after OpenMW has started.

pvdk wrote:
If you want to do it for me, go ahead Your knowledge of CMake is better than mine.

About the quitting of the launcher: Qt has a function called QProcess::startDetached, I think that'll do what we want.

pvdk wrote:
Zini, quick question:

Does it matter if a commit includes submodule updates? I have fixed my local branch regarding the Makefile but one commit refers to mangle and openengine.

Zini wrote:
I am not sure, if I understand the question. If you are asking if it matters if you modify a submodule, then the answer is yes. Changes to a submodule have to be commited/pushed separately to the submodule repository. Afterwards you need to commit the changed submodule reference in OpenMW.

pvdk wrote:
No, I did not modify the submodules. Git detects new commits on it and the commit contains the following lines:

Zini wrote:
I just pushed the path changes. You find the path function now in components/files/path.hpp. The interface has changed slightly.

pvdk wrote:
Thanks! Will look into it. Where should I save the launcher.cfg? Global or User directory (if they are both available)?

Zini wrote:
The user directory.

pvdk wrote:
Ok, I finally fixed all the problems with my git branch, it's up-to-date and clean and pushed to Github. Now I can finally continue with the code. You can see what it does now, and more importantly: what it doesn't

I've decided to just check for a User config as I believe there's no need for a global config for the launcher right now. Also, this makes life easier for me because QSettings doesn't allow reading from two files.

Note: the stylesheet needs to be copied by the CMake script, so you probably won't see a fancy scroll etc. Where should it be placed, installdir/resources/launcher?

Zini wrote:

I've decided to just check for a User config as I believe there's no need for a global config for the launcher right now. Also, this makes life easier for me because QSettings doesn't allow reading from two files.

That is probably not going to work. Depending on the installation and how we later handle data directory defaults, the data entry may only be found in the global setting file.

Note: the stylesheet needs to be copied by the CMake script, so you probably won't see a fancy scroll etc. Where should it be placed, installdir/resources/launcher?

I guess you mean

builddir/resources/launcher

That would work. And in the repository, place it somewhere under files/

Zini wrote:
Error report: The esm list is broken. Currently it is missing two esm's (Tribunal and Bloodmoon) and it is showing one esm that is not there (an old version of Redemption).
I still have a plugin for this old version of Redemption in my data directory. I guess this is where the additional esm is coming from. That definitely should not happen.

pvdk wrote:

Zini wrote:That is probably not going to work. Depending on the installation and how we later handle data directory defaults, the data entry may only be found in the global setting file.

Yeah I can see some default settings being found in a global config, but here's my problem: the launcher needs to read the config file every time the user changes profiles with the combo. I use a settings handler which I set-up and use afterwards for writing. What the problem is: it can only point to one file at the time.

A possible scenario I can think of where a global config (regarding the profiles) would be useful is with a Default profile with Morrowind, Bloodmoon and Tribunal. What we could do is load the global config once while setting-up the data but let the settings in the user config have preference above the same settings in the global config (ie: a profile Default existing but different in User).

Zini wrote:

builddir/resources/launcher

That would work. And in the repository, place it somewhere under files/

Exactly

Zini wrote:Error report: The esm list is broken. Currently it is missing two esm's...

Thanks for the error report. I was aware of this problem and it is because of this: The masters you see in the table are only the masters on which a plugin depends on. Because of this masters without plugins aren't added and masters which don't exist in the data dir get added without problem.
I need to add the actual masters in the data dir and a way of notifying when a master is needed but not there. (Coloring or so, is talked about before)

And now we're there anyways, I've been meaning to ask you something related:
is it possible for a plugin to not have any masters?

pvdk wrote:
Ok I made a small fix for the bug you encountered, all masters are loaded now but no warning is given yet if the master doesn't exist. (Not too much work but going to bed now)

pvdk wrote:
Update:
The launcher now writes to the openmw.cfg and I started working on the Graphics page. I managed to get the launcher to compile on Windows (for Direct3D testing). There are some problems with the icons (which I retrieve using the Freedesktop.org specification) and other minor bugs/visual problems but overall it looks quite nice. Have a look:

Note that I haven't pushed the Graphics page code to github yet.

Zini wrote:
Looks nice. And your timing is good too. Seems like you are almost done. I am going to do my last two OpenCS postings now. With a bit of luck we should be able to have a go at our editor very soon.

pvdk wrote:
I have a question regarding the icons on Windows. They aren't working, as you can see in the screenshots I posted. I searched all MSDN and the interwebs for a way to retrieve standard icons: turns out to be impossible. A homogeneous platform that Windows is does not provide the most basic of GUI element standardisation.

Now I hacked together a solution, which retrieves a bitmap from shell32.dll that contains the toolbar buttons like new, save, copy etc. The problem with this solution is that it uses an entirely undocumented bitmap file which is subject to change. (and it's not there anymore in Windows 7's shell32.dll)

Another solution would be to step away from standard icons (which is a contradictory term because there's nothing standard about them, except for their looks) and use some other iconset for the Windows version of the launcher

Agreed. Windows UI-"standards" and Look-and-Feel is a joke anyway. Pointless to waste any resources on it.

pvdk wrote:
Update: Here's how the launcher looks on Windows, with proper fallback icons in place:

I'm not that fond of the delete button icon, it has to resemble a paper shredder but to me it looks more like a blowdryer or a printer. If anyone knows some good (open source) icons which include a display icon, at least at 48x48 pixels, please let me know.

I also implemented the Graphics page and pushed the code to github. It's basically a copy of the code I had in place for the old launcher, with some changes. I'm not entirely happy with the code but it works for now, (as in: reads and writes Ogre settings)

To-do: Implement the new multidircollection and filtering of the Data Files.

just use the Octagon with the X in the middle.
or perhaps one of the 'recycle' bins.

hth.

pvdk wrote:
I considered that, as the current icon theme I'm using is Tango. But in my opinion these icons you suggest don't quite mean delete. (The octagon means "stop process/operation" to me and the recycle bin would suggest a recovery method, just like with the desktop trash bin)
What about this icon, it's from an earlier version of Tango:

pvdk wrote:
Update: finished the multidircollection integration and the filtering, all launcher-related tasks from the roadmap are now done:

However, there are still some things I forgot:
- Handle load-order sorting on a per-profile basis
- Context-menu in the plugins view
- Move items up/down

And some things I want to change:
- Don't use plugins.cfg for Ogre, as we only need the renderer plugins (speed)
- Change all QString() and unenclosed quotation-mark strings to QLatin1String(), which is much faster but offers the same advantages as unenclosed quotation-mark strings in a platform-independent way.

They are no show-stoppers for now however, as plugin support is not on the list for 0.11.

Zini wrote:
Not using plugins.cfg is probably more trouble than it is worth (you need to take into account the varying install locations). But if the speed difference is significant, you can add a second plugins.cfg file with a different name, that only contains the renderers

pvdk wrote:
I was planning to check if Qt supports OpenGL/Direct3D and load the supported plugins but you're right. I was a bit misguided by a piece of code I saw: qapp->isOpenGLAvailable() but it turns out it was custom code, not part of Qt. Also, as you point out, you would still have to figure out where the plugins are located.

I don't know if the speed difference is significant on modern computers. I do know that loading the plugins takes some time with Windows as a virtual machine. Maybe we should wait for this feature until someone complains the launcher is slow

Rhys wrote:

pvdk wrote:I considered that, as the current icon theme I'm using is Tango. But in my opinion these icons you suggest don't quite mean delete. (The octagon means "stop process/operation" to me and the recycle bin would suggest a recovery method, just like with the desktop trash bin)
What about this icon, it's from an earlier version of Tango:

That icon works well, or you could use + and - for add and remove.

pvdk wrote:
Thanks for the input Rhys, will use that icon.

Zini wrote:
How is the remaining launcher work coming along? Its been a while since we heard from you.

pvdk wrote:
That's right. Been busy with school and life in general.

Haven't worked on the launcher that much. Messed around with CEGUI to see what it offers (can't get a basic Ogre+CEGUI app to compile)

I'm currently stuck with getting the sorting to work the way I want: when you drag and drop a plugin in the list I want it to keep it's selection, so you can see where it went.
After that I'm going to implement the sorting of plugins according to the load order in the profiles.

I have some free time later this week, due to Ascension Day.

Zini wrote:
Okay. That means the launcher will most likely be ready for the next release. I think at least for the .deb package we need to adjust the cmake scripts to include the launcher. Having a .desktop file would also be nice (i.e. add the launcher to the application menu on Linux systems).

I think Hircine is our Linux buildier:

@Hircine: Do you know enough about packaging to do the task yourself or do we need to look for another volunteer?

Hircine wrote:
I downloaded the research data from my testing earlier in the year.
I will begin confirming the data and making sure formulae are correct or at least reasonably accurate, I will start on the 6th.

@Zini

I can compile stuff, but thats sort of the extent of what I am able to do.
I can certainly learn how to do a proper package.

again i mention the 6th again, because thats when i will be handing in my assignment and when i will be free for at least 2-4 weeks anyways.

pvdk wrote:
Update:

- The launcher now respects the load order in the profiles.
- A nice and dandy context menu in the plugins list for moving plugins
- Actions for the plugins, like refresh, move to top, move to bottom, check/uncheck (no use for a context menu without them )
- Dropped/moved plugins retain their selection so you can actually tell where they went. Note: Doesn't completely work with a filtered view but I'm happy with it working most of the time for now, it was a bitch to get working.

Not to detract, but I would like to point out that the plugin list doesn't show information such as "Author", "Summary", "Created On" or "Last Modified". As a matter of fact it doesn't show any information about the individual plugins at all. This is a loss of information vs. the original launcher. Is this a design decision?

Also, since there will probably be people wanting additional functionality in the main fork of the OpenMW releases down the road after the release of 0.11, why not give the launcher it's own version number to denote a semi-separate thread of development. This way, after 0.11, the development of further improvements to the launcher won't need to wait on the next release of the whole engine to be released.

Edit: I may have missed this earlier in the thread, but how are you supposed to determine the parent masters of the plugin?

Zini wrote:

Not to detract, but I would like to point out that the plugin list doesn't show information such as "Author", "Summary", "Created On" or "Last Modified". As a matter of fact it doesn't show any information about the individual plugins at all. This is a loss of information vs. the original launcher. Is this a design decision?

We decided to not have these information presented in the way the original launcher did, because it added to the visual clutter of the window and was hardly of any use to the end-user most of the time.
I think we talked about having it as a tooltip instead, but somehow this feature got skipped.

@pdvk: Can we have it as a tooltip or would that be too much for a tooltip window?

Also, since there will probably be people wanting additional functionality in the main fork of the OpenMW releases down the road after the release of 0.11, why not give the launcher it's own version number to denote a semi-separate thread of development. This way, after 0.11, the development of further improvements to the launcher won't need to wait on the next release of the whole engine to be released.

Too much complexity for too little gain. At a time we will already have to manage OpenMW and the Editor separately. Also, with this release I consider the launcher mostly finished. Maybe there will be some minor tweaking later on, but I don't expect the launcher to change much up to 1.0.0 or even past that. It already has all the features you can reasonably expect from a launcher.

Edit: I may have missed this earlier in the thread, but how are you supposed to determine the parent masters of the plugin?

For what exactly do you need to do that? I guess we could add this information to the tooltip (if we are going to implement a tooltip-based solution), but I don't see of what use that would be.

pvdk wrote:
Completely forgot about the additional information, but it certainly could be displayed with a tooltip. I just have to store the additional information while parsing every plugins.

The tooltip could also display the parent masters of every plugin, as that's only a single extra line for a tooltip which is pretty large already.

@Greendogo: Since plugins get loaded when the user selects its parent masters, it's quite easy to tell what plugins depend on what parents, even without a tooltip.

heilkitty wrote:

pvdk wrote:Anything else?

Selecting plugins and master files required for a savefile.

pvdk wrote:

heilkitty wrote:

pvdk wrote:Anything else?

Selecting plugins and master files required for a savefile.

Yes, we have to think about that when we support savegame files, which we do not right now AFAIK.

Zini wrote:
Correct. I would think that our profile systems removes the need for any additional save game management (beyond only showing matching save games in the in-game load game dialogue). But we can look at that again, when we have everything else working and probably some user feedback. If we do anything with saved games at all in the launcher, that would be a post-1.0 feature.

Greendogo wrote:
The required parent masters allow you to know what ESM/ESPs the plugin requires if you don't happen to have it downloaded yet. You're right, it probably wouldn't get used much because most mods have readme files.

Alright, if you don't want the clutter, I was actually going to suggest a tooltip, so that would work. However, some plugin summaries can be too long for a tooltip, so while for the most part a tooltip would work, I'd like a properties option in that drop-down menu that has the full collection of information, including everything in the tooltip, plus the parent masters and the dates. What do you think?

Zini wrote:
The description text is limited to 256 bytes. How can that be too long?

Greendogo wrote:
As long as it looks good, I suppose it doesn't matter. But my comment about a properties option in the context menu still stands, as I think it would put the entire sum of information about a plugin in an out of the way place.

Zini wrote:
We are generally trying to limit the launcher to one window. I am not entirely against your proposal, but we should try to make it more consistent with the rest of the launcher's design (and it is definitely a post-1.0 feature).
I guess we could add a plugin-inspector tab eventually.

pvdk wrote:

Greendogo wrote:The required parent masters allow you to know what ESM/ESPs the plugin requires if you don't happen to have it downloaded yet.

If you have a plugin whose master happens to be not installed, the launcher will tell you that. At least, that feature is not done yet but it's what I mean with "Warning for missing masters" in the to-do list.

Zini wrote:
How is that going to look GUI-wise? IIRC if a plugin does not have a matching master, it will not appear in the plugin list at all (because it will be filtered out).
Wouldn't it be best to move this feature to a separate plugin-inspector tab too? (which I still think is more a post-1.0 feature).

pvdk wrote:
I was thinking of something like this: missing masters get added to the masters table, albeit with a different background color (light red or something.)
When a user selects this master the plugins who depend on it get loaded, but are non-checkable and also have a different background color.

Zini wrote:
Loading a plugin if the master is missing does not make sense (never going to work, because for sure you will have lots of missing records). These plugins should be considered unusable.
As such I think they don't belong to the regular plugin-selection UI. Instead they should be handled in a future error-diagnosis UI.
For now that should not be a problem. There are simply not enough master files around yet. For a regular user an error situation like this should rarely ever arise.

pvdk wrote:
With "loading" I meant: showing it in the plugin table, not loading it with OpenMW But I believe users should not have to go to a separate tab to figure out what dependencies are missing. I believe working with different colors and non-selectable plugins in the table would work. Take for example someone who copied his profile to a fresh installation. In our current setup the profile would get overwritten without warning. Having the missing masters/plugins inside the table would enable us to give more feedback.

Or remember the problem you had with a Redemption plugin referring to a specific master you were missing.

Zini wrote:

Take for example someone who copied his profile to a fresh installation. In our current setup the profile would get overwritten without warning.

That is obviously not a good thing. Simply viewing a profile should not change it.

I would have thought, that the installed plugin/master collection does not have any influence on already existing profiles. But it seems you went a different implementation path.

Or remember the problem you had with a Redemption plugin referring to a specific master you were missing.

Well, that should count as an installation error. I forgot to delete the outdated plugin when deleting the old master.

My position here is that different tasks should be split into different UIs. Plugin management is not the same as diagnosing a faulty install.

It looks like the profile corruption problem isn't easily to overcome without a major rewrite of some of the internal plugin logic. Since we are already late with this release, I suggest we go along with your idea and maybe review the whole situation again post 1.0, when we have a better understand of in what direction the plugin-system will develop.

pvdk wrote:
Well, the fact that profiles can get overwritten while viewing them is a result of the "apply-instantly paradigm" or whatever it's called. Simply viewing them won't change a thing but as soon as a user switches profiles or closes the dialog, the profile will get saved over the old data.

My point is: the original launcher did not tell the user when there were dependency problems, but it just loaded every plugin in the Data Files dir. You could then tell by the errors that Morrowind gave while loading the plugin, or preferably by looking at the Parent Masters field, that something was wrong.

Our launcher does things differently, it loads the masters/plugins that are available in the Data Files dir, but only shows those with valid and existing masters, if selected. I figure it can be quite annoying to the end user with missing dependencies, as it would appear some plugins disappeared without a trace and without the ability to quickly diagnose the problem (that is: find out what parent masters a plugin depends on) Imagine someone who doesn't have the original Morrowind launcher installed. How is she going to know what masters are missing if the information she needs will only be reported in the post-1.0 launcher?

I agree with you on plugin management should be in a different tab, but this isn't about advanced stuff like merged lists or whatever. This is basic usability.

Zini wrote:

Well, the fact that profiles can get overwritten while viewing them is a result of the "apply-instantly paradigm" or whatever it's called.

Not really. You could display the non-existent plugins in a profile anyway (just in a different colour; to indicate that they don't exist). The user would then have the option to remove them from the profile (which would also remove them from the UI) or fetch the missing plugins/masters. In this situation the whole profile would need to be marked as broken/unusable until the problem is resolved.

How is she going to know what masters are missing if the information she needs will only be reported in the post-1.0 launcher?

Well, if something doesn't work, these days the default answer seems to be to re-install it. I would assume that plugin authors take care of their dependencies (at least by adding them to the documentation or maybe even by offering downloads that include them). We don't have a lot of usage data on this scenario at the moment, because there are hardly any master besides the three defaults. For the time being the case of "missing dependencies" will simply not happen.

In the long run (way past 1.0), I can imagine something like the package management on Linux, that allows automatic resolving of dependencies from a central repository. Making the user manually manage plugin-installation doesn't look like a good solution.

I agree with you on plugin management should be in a different tab, but this isn't about advanced stuff like merged lists or whatever. This is basic usability.

Seems we have to agree not to agree here. To me this isn't a question of basic and advanced, but of managing profiles and modifying/maintaining the installed set of plugins.

pvdk wrote:

Zini wrote:Not really. You could display the non-existent plugins in a profile anyway (just in a different colour; to indicate that they don't exist). The user would then have the option to remove them from the profile (which would also remove them from the UI) or fetch the missing plugins/masters. In this situation the whole profile would need to be marked as broken/unusable until the problem is resolved.

Yeah that's more like it. But let me explain a bit how the loader works right now. (Excuse the usage of the word "loaded," I mean "listed in the laucher")
You see, plugins don't get loaded from the profile file directly.
What happens is this:
1. Masters are loaded and put in the masters table.
2. Profile is loaded: the masters that are in the profile and in the masters table (thus exist in the Data Files dir) get selected.
3. Plugins that depend on those masters get listed in the plugins table.
4. Plugins listed in the profile are checked and moved to their respective load order position, if they exist at all in the plugins table. Otherwise they just get ignored.

To allow "broken" profiles would need plugins with missing masters to be allowed first, or else there will be no way to indicate what plugins are in the profile but are missing dependencies.

There is indeed a third catagory of plugins: the ones that are in the profile but do not exist in the Data Files directory. As stated above they currently just get ignored. We could list those as well but they won't have a tooltip as information is not available for obvious reasons.

Zini wrote:Well, if something doesn't work, these days the default answer seems to be to re-install it. I would assume that plugin authors take care of their dependencies (at least by adding them to the documentation or maybe even by offering downloads that include them). We don't have a lot of usage data on this scenario at the moment, because there are hardly any master besides the three defaults. For the time being the case of "missing dependencies" will simply not happen.

Yeah maybe you're right. It seems that Microsoft introduced that as a valid method of fixing problems Maybe I'm too much of a Schwarzseher here, and things like this won't be a problem.

Zini wrote:In the long run (way past 1.0), I can imagine something like the package management on Linux, that allows automatic resolving of dependencies from a central repository. Making the user manually manage plugin-installation doesn't look like a good solution.

Would be great if Hircine can do it, since I don't have experience with CPack and have no access to a Debian-based system. (I could create a virtual machine however.)

Zini wrote:
Not an expert on cmake either and especially not on how qt is used under cmake. But I can't make out any obvious flaws in your file.

pvdk wrote:
Allright, CMakeFile is modified and did some minor changes like warnings and filter input keyboard shortcut support.

Now I would like to know what should be in the readme.

Zini wrote:
Not entirely sure. We need the readme primarily for the OpenMW icon, right (the created requested to be credited)?

There is already a README specially for OS X, but I think it is outdated and not fully correct anymore. But maybe it could be used as a basis anyway.

Zini wrote:
I think we need to rename the launcher. Currently the binary is named "launcher". This is to unspecific, considering that it may be installed alongside other binaries on a typical Linux system.

How about omwlauncher?

pvdk wrote:
Fine with me and something I ran into myself right now, as I'm working on the .desktop file.

How should the application be named and what should it start? The launcher or the game? We could go for two .desktop files, one that starts the game directly and one that stats the launcher.

Also, (for 0.12) when the game is started without Ogre config file, is it possible to execute the launcher (if available) instead of showing the Ogre settings thingie? I could add a command-line option to the launcher to display the Graphics page when launched.

EDIT: what about the files like launcher.qss, or the launcher.cfg. Should they be renamed?

And what about a default launcher.cfg file, with the following content:

How should the application be named and what should it start? The launcher or the game? We could go for two .desktop files, one that starts the game directly and one that stats the launcher.

If the user wants to start OpenMW directly, he probably will use the command line. No need for a desktop file.

As a launcher application name I suggest: OpenMW Launcher

I think your .desktop file is at least missing a Categories entry. Otherwise it looks good.

Also, (for 0.12) when the game is started without Ogre config file, is it possible to execute the launcher (if available) instead of showing the Ogre settings thingie? I could add a command-line option to the launcher to display the Graphics page when launched.

That sounds reasonable.

what about the files like launcher.qss, or the launcher.cfg. Should they be renamed?

I have no idea what launcher.qss is, but launcher.cfg sits in the OpenMW settings directory. No name collision possible and no need to rename it.

And what about a default launcher.cfg file, with the following content:

Looks good.

pvdk wrote:
Spotted the Catagories myself, it's now Categories=Application;Game;
What should the comment be? Something like "An engine replacement for The Elder Scrolls III: Morrowind"?

The launcher.qss is the stylesheet. It also sits in the OpenMW config directory. It's included in the CMakeLists.

Should there be separate config and stylesheet files for the different platforms, because of the line endings?

And should the resources that are non-launcher specific, like the icon, go somewhere else?

Zini wrote:

Spotted the Catagories myself, it's now Categories=Application;Game;

Is Application valid here? I can't find this category in the documentation. Also, I would suggest adding RolePlaying.

What should the comment be? Something like "An engine replacement for The Elder Scrolls III: Morrowind"?

Okay.

Should there be separate config and stylesheet files for the different platforms, because of the line endings?

Doesn't git take care of this (if properly configured)?

And should the resources that are non-launcher specific, like the icon, go somewhere else?

I am sure there are default locations on Linux, though I am not exactly sure what these are. Probably somewhere in /usr/share. On Windows they can be placed alongside the binary and I have no idea about what to do on OS X.

I don't have any idea about right way to separate launcher and OpenMW itself. Create two bundles?

So we'll have OpenMW.app with its resources in bundle, and OpenMW Launcher.app with its resources in bundle, I think.

Zini wrote:
What exactly is the motivation for separating OpenMW and the Launcher on OS X? The user will only interact with the launcher normally. An advanced user might want to call OpenMW directly, but that will most likely happen from the command line. Is any of this a problem on OS X? If it is, then I am okay with two bundles.

pvdk wrote:
I copied the Catagory section from a mmorpg I found in the Arch repository, called Mana. But is RolePlaying valid?

Zini wrote:Doesn't git take care of this (if properly configured)?

I suppose git does this correctly, and it's something for the package people to check.

freedesktop.org wrote:Icons and themes are looked for in a set of directories. By default, apps should look in $HOME/.icons (for backwards compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order).

I think installing it in /usr/share/pixmaps is the easiest, as the /usr/share/icons folder has subdirs for each theme. Most other apps seem to install their icons in /usr/share/pixmaps, at least here.

But I was referring to the source. The openmw icons are currently in apps/launcher/resources. Should they stay there or should they go in /files or something?

Zini wrote:

I copied the Catagory section from a mmorpg I found in the Arch repository, called Mana. But is RolePlaying valid?

But I was referring to the source. The openmw icons are currently in apps/launcher/resources. Should they stay there or should they go in /files or something?

Yes. All resources should go into a reasonable sub-directory of /files.

pvdk wrote:
As you stated above and I just found out myself: RolePlaying is valid, the catagories are now Game;RolePlaying;

Are we talking about the other launcher specific resources as well? Like the icon theme it uses and the stylesheet images?

Zini wrote:
I would expect all non-source, non-documentation, non-buildsystem files to go into the /files subdirectory. But there are other places, where our current repository is violating this rule, so no point in being picky about it.

pvdk wrote:
Ah thanks, those files don't need to be installed as they get compiled into the launcher. But moving them now would mean some rewriting.

Update: Ok, I renamed the executable to omwlauncher and committed my .desktop file and default config. Will look into CPack now, installing Ubuntu...

corristo wrote:

Zini wrote:What exactly is the motivation for separating OpenMW and the Launcher on OS X? The user will only interact with the launcher normally. An advanced user might want to call OpenMW directly, but that will most likely happen from the command line. Is any of this a problem on OS X? If it is, then I am okay with two bundles.

Ok, I think it makes sense, we can put both binaries in one bundle. Where can I find the launcher and test it?

Btw, where I can find new general ReadMe? Can't see it on github.

Zini wrote:

Ok, I think it makes sense, we can put both binaries in one bundle. Where can I find the launcher and test it?

pvdk's newlauncher branch on github.

Btw, where I can find new general ReadMe? Can't see it on github.

That is, because it has not been written yet.

pvdk wrote:
Ok, managed to get the launcher to compile on Ubuntu 11.4. But now the libpng library version is incompatible with the version the application gets compiled with. It tells me it's version 1.4.5 but I have 1.2.44 installed
I even went so far as converting rpms to deb with alien but to no avail.

So what version of Ubuntu should I use? 10.4 LTS? Does that have all the dependencies we need in its repositories?

About the ReadMe: will do it this evening.

Zini wrote:

So what version of Ubuntu should I use? 10.4 LTS?

Yes. That is the one I use. Probably the most reasonable choice considering the whole Ubuntu-situation.

pvdk wrote:
Working on a readme, but since the wiki's still down I have some trouble with getting the right information. I could look it op in Google's cache but maybe someone can help me out here.

OpenMW: A reimplementation of The Elder Scrolls III: Morrowind
OpenMW is an attempt at recreating the engine for the popular role-playing game
Morrowind by Bethesda Softworks. You need to own and install the original game for OpenMW to work.
Version: 0.11
License: GPL (see GPL3.txt for more information)
Website: www.openmw.com
1. Installation
2. Credits
OpenMW:
Thanks to DokterDume for kindly providing us with the Moon and Star logo
used as the application icon and project logo.
Launcher:
Thanks to Kevin Ryan for kindly providing us with the icon used for the Data Files tab.
3. Changelog

EDIT: What about this, I included the version, the license and the website.
Will look into the changelog, how far should I go back?

Zini wrote:
Looks reasonable. I think you should also mention the license (GPL3).

For 0.11.0 the issue tracker has a changelog. Older changelog entries should be in the wiki.

corristo wrote:
made small mac-specific fix in launcher, sent pull request to pvdk.
I think it's going to work nice with both launcher and openmw in one bundle

pvdk wrote:

corristo wrote:made small mac-specific fix in launcher, sent pull request to pvdk.
I think it's going to work nice with both launcher and openmw in one bundle

I merged your pull request, thanks! You're the first contributer to the launcher on GitHub.

libpng warning: Application was compiled with png.h from libpng-1.2.42
libpng warning: Application is running with png.c from libpng-1.4.5

[rant]
And frankly, I'm done with messing around with Ubuntu. I have to add all kinds of PPA's to meet the dependencies and I think the problem lies there. I've checked libQtGui and the launcher with ldd and they both link to libpng 1.2, so I have no idea where it finds libpng 1.4.5, as it's nowhere to be found on the system.

How do people normally get Ogre and Bullet working on Ubuntu, without relying on some crazy PPAs? Why isn't there a community repository which actually contains some useful software, like Arch has? As a long-time Debian user I thought Debians repositories sucked/weren't up-to-date, but the same goes for Ubuntu I guess.
[/rant]

However, I think I can start messing around with CPack, but I can't supply .deb packages as my system is clearly not how it should be. I guess if the CPackaging works on my system, it should work on the system of the one responsible for providing the .deb (Hircine?).

EDIT: Disregard my rant, after including the following lines to the CMakeLists.txt it works:

Does the combobox work? What version of Qt are you using. Does the application output warnings (when started from console) when the combobox is clicked/focused? There are several bugs regarding Qt stylesheets on Mac in Qt's bug tracker so it's seems to be a common problem.

pvdk wrote:
We could make a separate launcher.qss for Mac, without the QComboBox styling.

But first I want to try something out. I want to change the QStyle of the combobox to QWindowsStyle or QPlastiqueStyle. Maybe the stylesheet works then. I make a branch for it tonight or tomorrow.

EDIT:
Maybe there's another solution. Could test my latest commit, it includes some stylesheet modifications that might just fix this problem.

pvdk wrote:
It seems this is a bug in Qt that also affects the GTK style, as both the Macintosh style and the GTK style don't have drop-down comboboxes but show a pop-up instead. These popups get styled by the stylesheet and at least in the GTK style a checkbox mark appears in front of the selected item.

This forces the combobox in drop-down mode, but that's not the behaviour GTK users and certainly Mac users expect...

Zini wrote:
Are we making progress? I would like to try a release again this weekend. It seems that the wiki will be down for a bit longer, so there is no point in waiting for it.

pvdk wrote:
Sorry for the late reply. A release this weekend is certainly possible. The only show-stopper is the combobox problem to which I haven't received input on what to do. To re-iterate a bit, the choices we have for the Mac and Gnome platforms are:

1. Supply a separate stylesheet for these platforms (can we detect Gnome/GTK with CMake?) which doesn't have the combobox styling part. That way the combobox will appear and behave like a combobox is supposed to on those platforms.
2. Force the combobox of those platforms to be a drop-down type combobox with the solution mentioned in my previous post.

Other things we need to do: finish the readme aaand can't think of anything else right now

Zini wrote:

can we detect Gnome/GTK with CMake

Since the same launcher binary can be used on a Gnome desktop as well as a KDE desktop, there is nothing to detect at build time.

pvdk wrote:
Yeah that's what I feared. What about the other solution?

Zini wrote:
As a GNOME user this wouldn't bother me much. As I understand it, that is a Qt bug, which probably will be fixed some day. As long as our implementation is functional, we can live with a workaround.

Star-Demon wrote:
No word from KDE users?

Don't make me dig out (and update...) my OpenSuse Box.

pvdk wrote:
KDE is not a problem here, as the Oxygen theme uses a drop-down style combobox. This works with the Qt stylesheet. The problem arises when comboboxes use a popup to show the list of items to select, as Mac and Gnome (GTK) do. The popup gets wrongly styled with the stylesheet stuff used for the drop-down itself, when it's not selected/activated.

No need for digging up old cameleons, I'm a KDE user myself.

Zini wrote:
Okay, another try? Release this weekend?

Work on the GUI features has slowed down. Else I could make a joke about us risking releasing 0.12.0 before 0.11.0.

sir_herrbatka wrote:
Let's just ignore this bug for now and call it "feature" IMHO it would be just fine to try find a fix for 0.12.0

pvdk wrote:
I'd rather implement the drop-down hack, as this bug is reported to Qt but as far as I can tell it will be fixed in a > 4.7.2 version, if it gets fixed at all. (read this article for more info on Qt and bugs)

Zini wrote:
I agree, but it seems that this problem is blocking the release for two weeks now. Seems a bit excessive. Or are there other left-over problems/tasks I missed? We are going for over three months without a release now and I would rather release a slightly imperfect launcher than making it four.

pvdk wrote:
Sorry Zini, did not get a topic reply notification. Is this the cause of the delay? I thought we had other problems regarding NPC rendering and such.

Well, with the drop-down hack the launcher is good enough for now in my opinion. Two weeks is indeed excessive but I was not aware of this being the sole culprit of the release problems. The fix for the combobox problem is in my git repo now. Maybe a Mac dev can test it to be sure it works?

Zini wrote:
NPC rendering is for 0.12.0 or even 0.13.0. The launcher is indeed all that is stopping us from releasing 0.11.0.
As for OS X testing, I suggest you send corristo a PM. He doesn't visit the forum that often, but from my experience he reacts very promptly to PMs.
Maybe we can finally get 0.11.0 out this weekend.

pvdk wrote:
Haha would be great! Finally. Oh and let's not forget the readme.
It's a bit stupid that it has taken so long.

I have PMed corristo.

Oh and the topic reply notification seems to work again, strange.

pvdk wrote:
To quote corristo:

corristo wrote:ok, looks good, I think we're ready for release

Now we just need a readme and we're done! Finally.

What's up with the wiki, when is it planned to be up again?

Zini wrote:
No idea. I guess it is done when it is done. No point in waiting for the wiki.

For the readme, let's go with the minimal solution for now. We should try to replace the Mac-specific readme file we currently have in the repository with a version that covers all platforms. But if that is too much work, we can also do it later. And we need to give credit for the icon. Everything else we can add in 0.12.0 or later.

pvdk wrote:
Yeah, but since the wiki's offline until further notice, where should the end-user find installation instructions and such? Maybe we should write up a decent readme this time, since we're already kinda late with our release.

Zini wrote:
Sorry, completely missed this post. Can you put together something quickly? We are so hideously late now, that getting it out soon is more important than having it completely polished. I am kinda worried that people are starting to think the OpenMW project might be dead.

pvdk wrote:
Yeah of course, been busy myself but I will see what I can come up with this evening. Will PM you or something next time I don't get a reply.
Oh and do we give codenames to releases? I can think of some fitting names :p

Zini wrote:
Nope. We dropped the whole codename thing.

pvdk wrote:
Too bad Well I made a start with the readme, just what I had before and some additions. I could not find good installation instructions.

Will look for those and finish it tomorrow.

Zini wrote:
Do I understand the situation correctly, if I say we are not progressing because of missing installation instructions?

If you build OpenMW from source a simple

sudo make install

should do the job (or whatever the equivalent of sudo on the respective platform is).

The Linux prebuild version comes as a .deb, right? So that is pretty much standard.

On Windows, I don't know. If our release package is an installer, it would be "run the installer". Else don't install at all and just manually start the launcher.

For OS X, I have no clue.

pvdk wrote:
Hmm do we need a separate catagory for Compiling then?

On OS X when you drag and drop the application to the list of installed applications, it will be installed automagically. But we should ask corristo

Zini wrote:
For those people who want to build from source, a section on building would be good. But since these information are in the wiki and the wiki is still down, I guess we can add it in 0.12.0. Maybe mark the readme file as WIP.

Zini wrote:
I merged in the new launcher branch and found several problems:

1. Doesn't compile because of a boost compatibility problem (fixed and pushed to github)

2. The graphics tab doesn't work at all. Nothing happens when I click on it.

3. The play tab looks a bit odd. I see two small buttons in a big window. Didn't you change the look of this page? (if not, then just forget it for now)

4. There is still a lot of debugging output on the console that needs to be removed.

Sorry, but not ready yet.

pvdk wrote:
1. Good
2. Should not happen, but did you compile openmw too? The launcher needs the plugins.cfg but should throw an exeption if it's not there I believe.
3. Looks like there's no launcher.qss in the launcher's working directory. CMake is to blame here but I don't see what's wrong with it.
4. Will remove the debug output.

Could you send me a pull request to merge my branch with your fixes?

Zini wrote:
Pull request sent.

2. Should not happen, but did you compile openmw too? The launcher needs the plugins.cfg but should throw an exeption if it's not there I believe.

There is a plugins.cfg. OpenMW runs normally. And I don't see any indication that clicking this tab causes an exception.

Edit: And I see a file named launcher.qss in the same directory as the launcher executable.

pvdk wrote:
Weird, would love to look into it but your Boost fix breaks compiling on my box. How did we fix that similar problem before?

Edit: I got it working on my box with a similar approach you used in this commit
Can you check if it works with your version of Boost?

pvdk wrote:
I can't reproduce the problems you have with the stylesheet and the Graphics tab. What version of Qt do you have?

About the debug messages: should I remove them all?

Zini wrote:

Edit: I got it working on my box with a similar approach you used in this commit
Can you check if it works with your version of Boost?

Works here.

I can't reproduce the problems you have with the stylesheet and the Graphics tab. What version of Qt do you have?

Still 4.6.2. (Ubuntu LTS)

About the debug messages: should I remove them all?

Yes, please.

pvdk wrote:
Ok, removed all debug messages.

How do you start the launcher? Do you double-click the executable or do you launch it from a terminal? Does it make a difference?

It should work with your version of Qt, I did not use stuff which is not supported in 4.6.

Zini wrote:
Normally from the terminal, but I just tried to run the launcher from the file manager. No change.

Zini wrote:
Your code for locating plugins.cfg is incomplete. It does not check the global location, which will cause problems with the installed version of OpenMW. Unfortunately that does not explain my problem.

pvdk wrote:
AFAIK my implementation is based on the one OpenMW uses, or was using at the time of writing that piece of code (or my interpretation of it). I'll look into it.

As for the stylesheet not working: I'm at a loss, as it works like a charm on my system and corristo did not have problems either.

Ok I added some debugging info to see if the launcher finds the stylesheet. Please test

/home/marc/OpenMW/openmw/apps/launcher/graphicspage.cpp: In member function â??void GraphicsPage::setupOgre()â??:
/home/marc/OpenMW/openmw/apps/launcher/graphicspage.cpp:194: warning: format not a string literal and no format arguments

Is any of this telling you anything?

pvdk wrote:
Yes it's telling me you're not compiling the version I have here. Debug messages like SJILDKIEJS were removed several commits ago, so make sure you are up to date.

Zini wrote:
Oops. I did build the right branch all the time. But I was running the old launcher executable instead of omwlauncher. Completely forgot that we renamed it. Works nicely now. Sorry.

pvdk wrote:
Edit: Removed all debug messages. Should Ogre create a log? And if so, what filename should it have?

Could you tell me exactly what happens in engine.cpp regarding to plugins.cfg lookup? I'm having some trouble understanding how it works.

Zini wrote:

Should Ogre create a log? And if so, what filename should it have?

It won't hurt. launcherOgre.log?

Could you tell me exactly what happens in engine.cpp regarding to plugins.cfg lookup? I'm having some trouble understanding how it works.

Pretty cryptic, yeah. And I am not sure if it is doing the right thing. We probably should throw it out some times in the future (I think we have a branch lined up for 0.12.0 that is exactly doing that). I suggest you ignore the implementation in in engine.cpp for now.
The right order is:

- use file in user directory
- if not present, use file in global directory
- if not present, use file in local directory

pvdk wrote:
Ok the log is now called launcherOgre.log and the plugins.cfg is looked for in the global directory too. Code could be more efficient I guess but it works.

Well then, release?

Zini wrote:
I am on it.

Zini wrote:
Okay. Done my part and PM'ed chewit. It is in his hands and the hands of the builders now.

pvdk wrote:
Right, I'm going to prepare the Arch Linux package.

Zini wrote:
Oops! Stop! Everything! Made a mistake!

Zini wrote:
Okay, fixed.

pvdk wrote:
Haha what happened?

Zini wrote:
The next branch was already marked with the version number 0.12.0. By merging it in, I also changed the version number for 0.11.0 to 0.12.0 (resulting in the --version option and the doxygen pages showing the wrong number).

lgro wrote:
I have a question about launcher - on clean install when there are no cfg files launcher can't write new config files - I have following error message (similar was sent by Corristo: http://d.pr/hKBq ):

Application asked to unregister timer 0x7c000016 which is not registered in this thread. Fix application.

// EDIT: I forgot to mention - launcher is from "config_cleanup" branch, but I think there will be the same behavior on "master" branch.

Zini wrote:

And another thing when I click "Close" button when "Data files" tab is selected then I have some strange message on console:

Haven't seen it myself, but from the description it is clearly a bug.

I have a question about launcher - on clean install when there are no cfg files launcher can't write new config files - I have following error message (similar was sent by Corristo: http://d.pr/hKBq ):

When there is no cfg file, the install is broken. Building OpenMW creates a local file when building and a global file when installing. Maybe the launcher has problems with picking up the right location. Or writing a local file when there is only a global file fails. Probably a bug too.

also there should be a place in GUI when user could choose a path to data directory).

Don't agree with this one. I think the launcher should try to pick up an existing Morrowind installation and set the path accordingly (there is a tracker issue for this feature).
When building. a local data directory is already added. And when installing a suitable default location should be set (don't think the current settings are good; we will have to review them eventually).
Anything else is beyond the scope of the launcher. A regular user should never need to adjust the data directories manually.

lgro wrote:

When there is no cfg file, the install is broken. Building OpenMW creates a local file when building and a global file when installing. Maybe the launcher has problems with picking up the right location. Or writing a local file when there is only a global file fails. Probably a bug too.

Hmm, it's probably a false alarm because I intentionally removed openmw.cfg - Don't know why but I was convinced that after installation there is no *.cfg files and launcher should create a new one. (When there is openmw.cfg in global/local/runtime location then everything is OK).

Zini wrote:
Just making sure that we are clear about this: There should be a global cfg file after the install, but not a local one, nor one in the user directory. If the user does not manually create one in the user directory (before the launcher is run) the launcher should create one there.

pvdk wrote:

lgro wrote:And another thing when I click "Close" button when "Data files" tab is selected then I have some strange message on console: