Using version control and forking, reviews are now overviews, SS Polaris delayed (again)

So I haven’t been making good on my Sunday updates in a while. In fact the last update was the 5th November! However, there are some big updates for today (Tuesday since I was busy this Sunday).

The website’s development is now being tracked and controlled with the version control solution Git, which in the simplest terms allows me to log every change I make to the website and reverse them if I made a mistake. It’s a huge safety net that gives me more peace of mind in case something goes wrong and effectively allows the core files of the website to be mirrored in the cloud somewhere. Git also allows me to branch the website into two separate solutions where I can work on multiple things without them interfering with each other.  When its time to compile the final product, these branches would be merged into one with the differences of each branch carefully accounted for.

Traditionally branching is used to allow multiple people to work on one project at the same time, but I have used it to fork the website into two branches:

  1. master: main website source. The layout and design of master is considered stable and I can add new website content without fear of issues.
  2. designDev: design development source. Here I am free to experiment with layout and design changes without fear of messing up the content. When a compiled change is polished to the point I want to apply it to master, I can merge the two branches’ stylesheets so the changes can be rolled out to public view.

The GitHub repository for Starfleet’s Path to 2265’s complete code and assets is hidden (a necessity since the PHP code of the website contains sensitive information such as the MySQL database password etc.), but you can view master as it is by simply using the site as normal or view designDev‘s progress by navigating to it via the link under “Site development” on the homepage. Whilst version control for the website was not necessary, I think its a cool thing that can really help the website’s development in the long run! Practicing version control is also an industry gem for software and game development.

In other news; Ship Reviews has been renamed Ship Overviews, a decision made in order to reduce any “authoritative” connotations from my opinions. These overviews are intended to give a brief about the ship in canon or non-canon, some basic background information, my opinion on the ship, and (if applicable) how I integrated the design into the website. To launch the change, the overview of SS Valiant is now up! SS Polaris has also been delayed again due to time constraints.

There are a few upcoming changes/fixes as well. A gallery of the website’s development progress will be up in Articles soon, intended to showcase how far this website has come! The search results are kinda messed right now and grossly out of date, so that needs fixing. Some layout fixes and improvements to the side menu will be rolled out soon as well (some of the first major things to come out of designDev).

Advertisements

New site colour, upgraded search, SS Polaris delayed

First thing first: weekly updates will be on Sundays now since my week is getting busier and busier.

So after finally realising the issues with contrasting red and blue, the side colours are now red and medium grey for the time being. For now I think the colours look nice and modern, but it is likely going to change in the future.

20171105_desktop

A change that you will not notice from looking at the site is the upgraded search. I finally upgraded to using PHP data objects (PDO) instead of using raw MySQL calls. Chapter 1 has gotten a few updates too with the inclusion of UESPA-9 (FINALLY) and ship sideviews packed with the narrative.

UESPA-20 (SS Polaris) designing has been delayed for a week or so whilst I make changes to the website elsewhere. I am also working on my personal portfolio website as well, which is taking up some of my allocated website development timeslot within my week.

That’s all for now anyway. Have a good bonfire night everyone!

UESPA-9 finished, early warp reactors added

Well, I’ve just finished my UESPA-9 design in time for today’s update! Take a look at the development of the design:

uespa9_final
Late-August to mid-October 2017 development

I should make it clear than not everything about the design is finished. An orthographic and internal schematic is yet needed to give a complete picture, but this complete sideview will be enough to allow me to begin incorporating the design into the website fully. By the end of today, I should have most of the ship’s database entry done. By this time next week, I should also have a few paragraphs about the ship written for insertion into chapter 1. For now, you can read more about the design here!

Another significant addition to the website is a section of the (currently only UESPA) database dedicated to warp reactors. Since reactors are probably the single best way to signify technological development in starships, I decided it was time to put some attention there. Currently, information on the Cochrane-type fusion, Yoyodyne-type pulse fusion, and Cochrane II-series fusion reactors is present (which are written in chapter 1 and 2 to be the most prominent reactors in the mid-to-late 21st century). A Yoyodyne II-type pulse fusion reactor page will be done within the next few days to compliment the completion of the DY-732-class ship database entry next Thursday.

Have a good evening!

Fun planning, dank milestones. KAubersnek style.

So, the results from yesterday.

You will be pleased to know the solution works! I have yet to do extensive/thorough testing, although I am doing on-the-fly debugging in the meantime until I achieve this first operational milestone. And that is what I want to talk about. Milestones.

I do love my planning, and I have thought out a fair bit about what I want the program to be once it is done. So far, I have a well-defined operational milestone that I am dubbing “Full Operational Capability” (very professional sounding). This milestone is reached once the core functionality of the browser is complete. That means no advanced developer tools are being added at this stage, nor will the styling be finalised. Basically, the following criteria must be met:

  • Basic web functionality
    • Direct navigation
    • Past and forward history traversing
    • Native search query forwarding
  • Basic user settings
    • Home page setting
    • Search engine setting
    • Basic UI layout settings (hiding the bookmark bar, etc.)
  • Basic bookmarking system
    • Tab-based bookmark-managing functionality
    • UI bookmark bar
  • Basic ‘luxuries’ (you could consider these non-essentials)
    • Custom source code view
    • Custom context menu for default right-clicking within the GeckoWebBrowser
    • Custom download management capabilities
    • InPrivate browser

This milestone determines how far the project will go. If I am unable to create a usable web browser by not meeting this criterion, I will either cancel the project or postpone it until a time I have learnt what I need to know to complete this. Remember, I am always learning.

However, if this milestone is reached, I will then begin work on the next two milestones:

  1. Developer Tools Completion
    • This stage involves implementing some of the advanced developer features that the project is designed to accommodate. This includes the addition of a non-WYSIWYG webpage editor with helpful options designed to speed up the development of HTML and CSS code without the clutterful and fun-sapping ways of WYSIWYG designers such as Adobe Dreamweaver. This functionality is currently being explored in a project called “KAubershark”, which I am not prepared to reveal yet (it is still very rough and early)
  2. UI Design Unification
    • This stage involves finalising the overall design of all aspects of the software. This includes making the design unique and unified across all forms, dialogs and controls. After this is done, the project will be complete.

I have not gone into too much detail for these milestones in case of further refinements to the ideas. What I gave you is a basic brief of what the work entails, but I do have other ideas that I am still playing around in my head with. Work on ‘KAubershark’ is currently on hold until the first milestone is complete. It originally started as a standalone idea as a non-WYSIWYG development suite, and what code I have done for it is currently in a separate solution. That work is mostly rough and is for the purpose of exploring the plausibility of the idea, since it will naturally be a huge task and I want to make sure it is worth the effort. The final way I am going to implement KAubershark is not finalised either. My two options are to integrate the work into KAubersnek’s solution, or keep it as a separate standalone software and add a bridge for the two applications to access each other.

So that is it for this post! I hope you appreciate the insight, and please watch this space!

Problem-solving. With KAubersnek

Straight into this.

KAubersnek is my project to create a personal (and only for me at this point) web browser that will aid me in developing websites by providing me with custom developer-focused tools (and will serve as a piece within my future portfolio of work). However. Currently, I am far from realising that goal. But for now, I have been making considerable progress in maturing the basic web browser itself into a usable frame to work with.

2017-06-18_1508
KAubersnek as it looks currently (2017-06-18)

The UI is currently based heavily on the open-source Chromium (of which Google Chrome is a well-known release of) UI. But one of the goals for reaching what I am calling the “full operational capability milestone” is to have a custom tab design. However, designing the UI is currently taking a backseat role in favour of allowing the UI to be more flexible for when I add crucial features take enable the browser to be fully operational.

So that’s pretty much the overview, but today when I was working around a me-induced bug/oversight, I thought that I might be cool to write down this problem with a methodical solution so that I could convey what it is like to be a programmer (at least in my eyes) when solving a problem. Here goes nothing. Also, one more thing. This is written in a way that allows it to be understood (I hope) by almost anyone with at least some basic idea what programming is like. To that end, I will be attempting to explain some of the more complex concepts that people might have trouble getting their heads around. But I at least hope you know what a class, object or a control is. If not, you might want to look them up first.

The problem
When loading a website in the browser, you had to remain on the current tab until the page was loaded. Otherwise, switching tabs during the download resulted in some of the results of the download (namely the website’s title) being applied to the wrong tab. This was because the code originally forwarded the downloaded title from the user control the GeckoWebBrowser object is a member of, to the currently-active tab on the TabControl object which is housed on the main form. As aforementioned, this was a simple oversight as it was just a case of the data being sent to the wrong object in some specific cases.

What it looks like
2017-06-18_2125.png

Listed process ‘chart’

  1. A webpage download action is taken by the user within the browser; via URL navigation, web search or hyperlink navigation
  2. The user switches tab whilst the download is in progress
  3. The download completes within the other tab, and the DocumentComplete event is triggered on that instance of the browser
    • The DocumentComplete event gets triggered when the GeckoWebBrowser object declares that it has finished downloading the webpage and its content
  4. The DocumentComplete event code sets the text of the currently-selected tab as the DocumentTitle of the downloaded webpage, as reported by the GeckoWebBrowser
    • There is no check/flag to see if this is the correct tab that actually contains the user-created control with its GeckoWebBrowser

Analysis
The reason why this is not a simple cakewalk is because of how the structure of the program is. It is not one large object called ‘browser’. The ‘parental’ structure that I have to deal with looks like this:

  • The actual powerhouse under the hood (that is the browser) is the GeckoWebBrowser object.
  • The GeckoWebBrowser object is housed within a user-created control, which is a class that contains the GeckoWebBrowser object and all the controls needed to operate the browser at the basic level (buttons, address box, options menu, progress bar and status display label).
  • This user-created control is docked onto a TabPage object when the tab is first created. This TabPage is actually the object that contains the crucial property known as ‘Text’. This property is what gets updated each time a webpage is finished being downloaded.
  • The TabPages are then added to the TabControl’s TabPage collection. This collection is then represented as clickable tabs on the main form.

With that in mind, you can begin to picture what the issue is. Although the user-created control is docked onto a TabPage, that user-created control does not have a native ability to tell what its ‘parent’ object is. So, when the DocumentComplete event proceeded to update a TabPage’s ‘Text’ property, it does not care or recognise if the user switches TabPages by clicking one of the visual tabs. It just updates the selected tab. This problem is an oversight because I should have seen it coming, since I must put more code in to fix this either way. Now that I see what the issue is, I can now easily implement my three-part solution.

Solution

  1. I added an integer variable inside the user-created control called ‘intPosition’. This variable will store a value that indicates what position its parent TabPage should be at within the TabControl’s TabPage collection (known as index). So now the code that updates the TabPage’s ‘Text’ will know what TabPage to apply the change to. This position variable is initialised as soon as after the user-created control instance and its mounting TabPage is being created, and the value is based off the current number of TabPages within the index.
  2. I also added some code that updates the position variable in all opened instances of the user-created control when there is a change within the index. Changes to index are made when a tab is opened, closed or moved around. So this code is a must for such scenarios. For example; if I had three tabs open and I close the middle one, the third tab will have its position variable updated since it has now become the second tab in the index, and the browser would need to know that otherwise the program would literally DIE in runtime. Okay. Maybe not that extreme. But it would be bad.
  3. The code within the DocumentComplete event is updated so that it references the TabPage it needs to access via the index (cross-referenced with the position variable) instead of accessing whatever is the currently-selected index is.

Code (You’ll have to excuse the amount of comments. They’re just there to explain the screenshots.)

2017-06-18_2103
Code that creates the user-created control instance and TabPage
2017-06-18_1941
Code that updates each instance’s position control variable

Conclusion
I actually have not tested this yet. It is almost the end of today, so I will enjoy a sleep before I make sure the changes work. In theory, this should work no matter what however. But I will let you know tomorrow. My next post on the subject will go more in-depth about the goals and milestones of the project.

Anyway, I hope you enjoyed the read! 😊