Well, I’ve just finished my UESPA-9 design in time for today’s update! Take a look at the development of the design:
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.
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
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
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:
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)
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!
KAubersnek is my project to create a personal (and only for me) 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.
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
Listed process ‘chart’
A webpage download action is taken by the user within the browser; via URL navigation, web search or hyperlink navigation
The user switches tab whilst the download is in progress
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
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.
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.
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.
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.
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.