GUI - Journal Window

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

GUI - Journal Window

Post by lgromanowski »

Star-Demon wrote: Been having a lot of internet disturbances, but I'll post more in detail about my thoughts within a few days.

We should discuss the basic parts of the journal and find out how to efficiently lay everything out, how to spread text out, and how things should work and what means we have to do all of this.
Star-Demon wrote: To my recollection, time *does not* stop when journal is open, but the game *does* stop.

The journal window can be a single window with three or more "pages" that are displayed on it. Sorry for not using GUI terminology, I still have to brush up on it.

The first is a linear Journal, which I imagine is stored as a linked list, since the loading times are so slow. The text is divided up between two journal pages, so either we create two textboxes that we can split text between or make a single large textbox that has a large space inside of it. I prefer the first, since we can easily number pages this way - they don't change once written, so maybe making new pages while writing journal text is acquired is the way to go?

the second is a topics page, which has an alphabetical index of topics - you push a letter, you get a list of topics with that letter. Takes forever because of reading linked lists with no saving.

The third is a quests page - push text, get all responses related. Probably takes forever due to linked list building and/or reading.

Arguably, there are more than three pages because the three functions transform into multiple pages. You have an index page then display page in two of the primary functions.

Keywords from the topic list are automatically highlighted in all instances.

Hircine - any thoughts?
Zini wrote:
To my recollection, time *does not* stop when journal is open, but the game *does* stop.
Not sure what you mean here. If the game stops, the time stops.
The journal window can be a single window with three or more "pages" that are displayed on it. Sorry for not using GUI terminology, I still have to brush up on it.
The original interface looked different. But I think this is one of the few cases, where it is pointless to follow the original (because of extremely poor usability). Maybe you could implement the three modes via a column of bookmarks either on the left or the right side of the book?

Edit: And don't worry too much about the performance. For most parts it should not be a problem; the only exception being the primary journal. IIRC by default it opens on the last page, which means you need to format all the pages when it is opened. That might indeed take a moment, but we can not do anything about that. Obviously you need to cache the formatting, so it can be reused when the user reopens the primary journal.
Star-Demon wrote: I play a rather healthily modded game. I have easily 270 pages of Journal. It's slow. I'm worried about performance. :)

If you're willing to axe the original game's Journal design and see if we can improve it pre-1.0, I am all for it. The original journal was really uncomfortable, slow, and clunky.
Zini wrote: Just don't let the redesign get out of hand. The journal GUI is a big task already and we don't want a large redesign that takes a long time and pushes 1.0.0 further back. I think if we can just optimise the navigation between the 3 journal modes, we should be good for now.
Star-Demon wrote: That's the general plan I have in my head - I wish I could have an extended conversation with Hircine, but for now I'll just think about it before I do anything.

Just a note: I've been having big disruptions of service during daytime hours - it's tough for me to get things done for anything, but I can still stay in touch easily, just not all day every day like usual. Looking to get this resolved so I don't spend the day bored out of my skull.
Hircine wrote: i think a well-thought out journal design would be better than original, it has to have the look and feel of the old one, but better layout and navigation.

we don't have to load the entire journal, since the game 'stops', we can allocate more IO to jounal loading and unloading and only show what we need.


will have more on this later, really hard to get to a comp for the rest of the week.
Zini wrote: This isn't a question of loading. The entire journal is loaded on startup. Its a problem of text formatting.

Since the length of a journal entry is not constant and we start at the last entry, we need to format all entries to know where on the page the last entry starts.
Star-Demon wrote: Well, playing some Morrowind - I notice that the index is always pasted to the right side of the book, usually forcing you to scroll, and usually a LOT of scrolling - maybe one simple but faithful improvement would be to have the topics and the quests index use both sides of the book?
Zini wrote: Any progress? I haven't seen any code from you two yet.
Zini wrote: btw. I had an idea about using both facing pages for the index (topic/quest).

How about we place a filter on the left page? This should contain a list of all letters a quest/topic begins with, plus an "all" option. For quests we should add a choice of "finished", "unfinished", "all" on top of that list.

The right page would then show a list of topics/quests that match the filtering. By clicking on a list item the right page would show this topic/quest instead. In this view we should also have a next (next topic/quest in filtered list), prev (previous topic/quest in filtered list) and up (back to filtered list) button.

If anybody is wondering, this is basically a reordering and slight generalisation of the original MW journal GUI and as such it fits our paradigm for 1.0.0 perfectly.
Star-Demon wrote: I'll be able to do a LOT more once I get internet back during the daytime. I'm having some hard times, right now.

Hircine - We probably should converse via PM on what to do for now.

I'll have to take a close look at the book and scroll stuff and then see what I can draw from it.
Hircine wrote: Star, you get my last two pm's?

one was a recorded convo and the other was a rather large image with notes on it. just making sure it hasn't been lost :)
Star-Demon wrote: Reading. :)
Star-Demon wrote: okay -
Internet is back during the daytime - so I can do more stuff.

I'll try to brush up on MYgui as it's done in the project. I'm really appalled there's no examples or explanations on their site.
Zini wrote: I assume there is an active PM exchange going on between the two of you. That's okay, if you prefer it like that, but usually we do this kind of discussion out in the open here in the forum. That allows other people to see what is going on and to provide additional input. Also your task heavily overlaps with another one, which should make using the forum even more profitable.
Star-Demon wrote:
Zini wrote:I assume there is an active PM exchange going on between the two of you. That's okay, if you prefer it like that, but usually we do this kind of discussion out in the open here in the forum. That allows other people to see what is going on and to provide additional input. Also your task heavily overlaps with another one, which should make using the forum even more profitable.
I'm thinking about what to do. I'm playing with it.

Here's what I'm thinking.

Code: Select all

  //JOURNAL TASK - EXPLORING//

#ifndef MWGUI_JOURNAL_H
#define MWGUI_JOURNAL_H

//Not sure if needed. Need to look at other gui elements.
  #include "window_base.hpp" 
// I'll need to grab topics from data.
  #include <components/esm_store/store.hpp>
//I also need access to player's esp
//include something else.

  #include <list>
  #include <vector>
  #include <string>

  class JournalWindow : public OEngine::GUI::Layout {
  public:
     enum JournalMode
      {
        JM_Read = 0,         // Reading
        JM_Topics = 1,      // View Topics
        JM_QuestsActive = 2,     // Only Active Quests
        JM_QuestsAll = 3       // All Quests
      };
private:
   JournalMode journalMode_Current; 

    //STORES PLAYER JOURNAL - IS ALL OF IT BUILT ON GAME LOAD?
    std::vector<string> player_Entries;

    //STORES ALL TOPICS THAT PLAYER KNOWS ABOUT - CONSIDER LINKED LIST, SAME AS MW's DATA.
    std::list<string> player_Topics;

    //STORES QUESTS - I DON'T KNOW HOW MORROWIND DOES THIS, SO THIS IS A PLACEHOLDER.
    //std::vector<Quest> player_Quests;

public:
    JournalWindow(int w, int h)
      : Layout("openmw_JournalWindow_layout.xml")
    {
      setCoord(0,0,w,h);
    }

    JournalMode getJournalMode() { return this->journalMode_Current; }
    void setJournalMode(JournalMode m) {}
    
    std::vector<string> getplayer_Entries(){ return this->player_Entries; }
    //std::vector<string> setplayer_Entries(){}    //not needed, really

    std::vector<string> getplayer_Topics(){ return this->player_Topics;}
    //std::vector<string> setplayer_Topics(){}    //not needed, really

    //Let's make this easier.
    void addEntry();
    void addQuest();
    void removeQuest();
    void addTopic();
   //and easier...
    void buildPlayerJournal();
    void buildPlayerTopics();
    void buildPlayerQuests();
  };

#endif
I am interested in taking a look at some other stuff around the project for advice, but haven't done it, yet. Right now what I really need to know is how Morrowind stores the player journal and what includes and functions I need to manipulate data. I'd wager some of this belongs to the player and not to the GUI, but I have no knowledge about the player's data.

ALSO: I just wrote this in notepad ten minutes ago. I know there are syntax errors. I'm making edits on this side..
Zini wrote: Okay. I suggest to use Gist for showing larger pieces of code from now on (Gist is a pastebin-like feature on github). The bloody fixed-sized layout of the forum makes it a bit sub-optimal for longer lines.

I have a few comments:

1. window_base defines a base class, that sits in between Layout and the leaf class. I am not entirely sure what window_base does, but if you don't use it, you don't need to include window_base.hpp either.

2. You don't need to interact with the components at all. The journal class provides you with a convenient interface to all journal data you need.

3. The journal window should know how to position and size itself, so there is no point passing size information in the constructor.

4. I don't see a use for the get-functions (journal mode, entries, topics).

5. The addEntry, addQuest and addTopic functions should probably be private and there is no point in removeQuest, since you can't remove quests.

6. The build functions should probably be private too.

7. Not so sure about the data structures. Simply storing topics and quests seems redundant, since the journal is already doing that. Don't know what would be needed. Depends on how the actual GUI is implemented.
Star-Demon wrote: 1. okay
2. okay
3. okay
4. Those are private members. You need some way to access them.
5. They are for being accessed from outside the class without using elaborate statements that are messy to look at. They should be public.
6. Yes.
7. The journal isn't doing that. The journal is simply a list of text entries. The topic responses are added as player talks to NPCs - and if you notice that many responses end with ClearInfoActor, it seemed to me that there's more storage going on than I know.

So - I think there are three sets of things being stored, or a single set of an elaborate structure (DialogueEntry?) that is having all sorts of things accessed. The first makes more sense.

Topics and responses are stored as linked lists in Morrowind - I haven't seen anything for quests yet - but it does come together visually in the journal. That's why I have three things.
Zini wrote: 5. But you don't need to access them from outside of the class. The journal GUI will not receive notifications about new quests and such. Upon opening/re-opening the journal window it is supposed to look for changes in the journal data and update what is displayed.
I think we can safely get away with assuming that the journal will not change while the journal GUI is up (since time is put on hold).

7. The journal is doing that. I have written it that way. Just to make sure we are talking about the same thing: MWDialogue::Journal in apps/openmw/mwdialogue/journal.hpp. Right?
Star-Demon wrote:
Zini wrote:5. But you don't need to access them from outside of the class. The journal GUI will not receive notifications about new quests and such. Upon opening/re-opening the journal window it is supposed to look for changes in the journal data and update what is displayed.
I think we can safely get away with assuming that the journal will not change while the journal GUI is up (since time is put on hold).

7. The journal is doing that. I have written it that way. Just to make sure we are talking about the same thing: MWDialogue::Journal in apps/openmw/mwdialogue/journal.hpp. Right?
Well, that clears up a lot.

bbiab.
Star-Demon wrote: Well, after some coffee and some Sherlock Holmes...

I'm happy that you wrote something for it already. I thought part of our task was to invent this particular wheel.

Once again, though - I wish I had known about that beforehand.

I suppose I'll get back to the drawing board later today and lay out a new version after studying the class. Hircine and I are working out features - but it's never too early to work out a basic class to put it in.
Zini wrote: Well, normally I would point you to our online doxygen documentation. But the journal is a new addition in 0.11.0 and since the release has been delayed I hadn't uploaded the new version.

As a workaround I just uploaded a preliminary version of the 0.11.0 documentation to the usual place.
Star-Demon wrote: What?

Okay.

Time to hit the books!
Star-Demon wrote: After some discussion, I have the displeasure of coming today as the bearer of bad news.

From what we've discussed on and off over weeks, Hircine and I have been trying hard within our powers and time to make sense of both MYgui and gather whatever knowledge and skills of the project we can in order to get some stuff done, and we're not going fast enough.

We discussed two solutions to the problem:

The first is to continue waiting for the wiki to come back up and be developed, scouring the internet for information, examples, and generally hit the books on all fronts while working. All this requires is time and determination.

More time than him or I can know - the practical uses of the very good Journal class are not known to us unless we take even more time to study them, as well as how the data and information that will be passed to it are stored, gotten, and passed correctly to expectation of the design of the program. We don't know how it works, so we'll need time figure that out, even before MyGUI is even touched.

The task can be done, and I see no problems save only MYGUI's lacking community and support combined with studying OpenMW even more simply slowing us to a crawl. Learning is slow and harsh, and anyone that comes here needs to learn.

The second is the relinquish the task until we either have the knowledge and information on hand to get it done, or someone with more intimate knowledge or experience with MYgui and OpenMW does it faster than we could and we can find more productive things to do. It would be more responsible to hand the task off so it gets done faster if we find we can't do it for whatever reason, and to be frank, we can't do it right now, and we're finding we won't be able to do it even less soon enough.

So we've come to the second. I feel like it's giving up (I detest it) - but I'll be taking myself off the task. Hircine seems to want to change focus, and I'd like to do the same - I'd like to have the wiki back up as soon as possible - since I'd like to finally deliver on some things I'd said I'd do in passing and in seriousness - namely, real documentation and inserting more MSVC Love and explanatory comments into code so fewer hours of study are needed by everyone else, including myself. Maybe if a better task comes up that involves data or gameplay elements, I'll take that instead.

This brings into issue the real difficulties with using myGUI from a human perspective. I very much understand the current arguments for it, as well as keeping it - I've even fashioned arguments cautioning about changing, but going forward - unless two or three expert people want the burden of doing this themselves, including the tasks they feel are more worthy of expert skills and time, then this is how it's going to be until we make the support ourselves, switch, or don't have to do it anymore.

I can't tell you which is right. I don't know right now.
Zini wrote: Okay. Changed the status of the task back from assigned to confirmed.

I can understand that getting into MyGUI can be a bit daunting. Luckily peppe seems to have become a bit more active again and he has a very reasonable working knowledge of MyGUI. I don't know if he can find the time to take on a feature by himself, but even as advisor he is pretty useful.

There is a point I feel I have to comment on though, even if that means I get a bit of flak for it. Yes, some areas of OpenMW are underdocumented. Yes, some parts of the code base are a bit obscure; mostly because of an early design flaw had to be compensated (we talked about that before) and also because in a few places my and Nico's design are still clashing.

However the Journal is not one of these problem zones. It is sufficiently commented and pretty simple (only a few classes and structs, each with only a few functions). Assuming a reasonable knowledge of C++, including STL concepts like containers and iterators and of Morrwind (what is the main journal, how does a quest journal entry look and such), it should be easy to understand. if you have serious problem with handling it, this more likely indicates you have a hole somewhere in your C++ training (or in your understanding of Morrowind) than a problem with the OpenMW documentation.
Star-Demon wrote: All right, I tried REAL hard that time, but I've had enough of that.

I'm not going to sit here on the interblags and be a punching bag simply out of politeness.

Honest to God...It's like I'm talking to a graduate TA...

You're right, Zini. It's because I suck.
And if anyone else is having a problem, it's because they suck, too.
I hope everyone feels good about that.


I said it was a good class - I wouldn't have bothered saying that unless I understood it. It's the very class I set out to write before you told me it existed and then told me to stare at the project in silence before doing anything. I'm not talking about the damn Journal class. Surprise!

You completely missed the point of my post in favor of defending a class you wrote that I actually had no problem with whatsoever, along with insisting that the here-and-there comments that exist of how anything in this project actually works together and how others can build on it, then proceeded to take a obligatory but completely unnecessary and unhelpful potshot at my skills, which I expected and was one of the reasons why Hircine and I agreed that I be the one to write this post to begin with.

Why don't you go insult Hircine and Obsidianblk, next?

I outlined, as best I could - without resorting to metaphors which would have served me much better - the problems we both were having and were going to have soon enough that led to deciding to drop it and find something else to do. I have a job interview tomorrow, and I have school coming up. I'm sure Hircine has a life, too. I haven't been able to get much done as is, and without a working wiki; with the only real support the library we're using has being "Go away, figure it out", It'd be easier if we let someone who's been doing existing gui work do it - we'll find something else to do. We gave it a real shot, and it's not working out. Much like a Grad TA, Your comments are unhelpful and not welcome.

Hircine told me what he's done so far, we talked about what our problems were and what we could do about them, but it's not getting done on time, we're losing motivation to continue, and I made that clear.

So -if you want to chock it up to a lack of skill, and insist that everything is fine and wasting time staring at the project and scouring the internet for things other than automatically generated documentation is a great use of someone's time and will get tasks and releases done on time - then I guess you just volunteered to do a lot of work by yourself. Better work fast.

In the meantime, all of us skillless casual scrubs that are ruining the genre will be reading books and function signatures until something or someone meaningful and helpful appears.

By posting like that, (talk about shooting the messenger) the next time something like this happens - the incentive will be to keep everyone in the dark and let you eat silence. It won't be the first time, and it probably won't be the last.

Hircine and I were doing the right thing, and you just shat all over it. Thanks.

I'll take my hole in my training under advisement, Thank you very much.
Peppe wrote:
Star-Demon wrote:I'm not talking about the damn Journal class.
So what are you talking about?
I can't say it's entirely clear to me after reading the past few posts.

What I got is that there is some problem somewhere, and, after the last post, that it is not with the journaling parts of MWDialogue.

Is it a conceptual problem? A design problem? An implementation problem?

Unless it is clear to everyone where and what the problem is there will be misunderstandings...
Locked