kinten108101 / steam-vpk Goto Github PK

Currently, each boxed list requires a class definition - the only way for me to set up and access boxed list objects. On the one hand, it is only for demonstration purposes. I did not know how to look up objects.

In this issue

Acceptance

• Multiple lists can be

As a user,

I want the ability to import a human-readable add-on list file into my profile, and to export an add-on list from my profile.

So that my add-on preferences can be shared and backed up.

Specifically, there will be new commands in the profile bar (omnibar)

• Import add-ons from file...
• Export add-ons...

And new features:

• Refresh

• Manual save for changes to the add-on list

• Auto save for changes to the add-on list

Some rules:

• The refresh and save features should be commands in primary menu UPDATE 11/5: For now, stay as accurate to the mock-up as possible.

• Auto save is enabled by default and whose interval can be configured in Preferences.

• Importing an add-on list file will replace the current add-on list with a new one.

• If an add-on is referenced but does not physically exist, it will be blanked out in the add-on list page and will be downloadable in the downloads page.

As for the add-on list file, it will be a JSON file and will look like this:

As a user,

I want a logo to associate with the program,

So that the program looks finished and appealing.

Acceptance criteria

• Blends in with GNOME circle of apps
• Has L4D2 branding

Progress

• Sketch
• MVP
• Final

As a developer,

I want to make the best initial commit,

So that the best development patterns may be set in stone.

Tasks

• (delayed) Flatpak build must support Node packages. See #37

• (delayed) ts-for-gir should generate definitions from libraries in org.gnome.Sdk and org.gnome.Platform.

Acceptance criteria

README

• Strong, straight forward wording
• Logo and images either self-owned, otherwise should not be included.

Other files

• No personal files (what about in gitignore?)
• No personal comments

As a user,

I want to view the authors of this application and their contacts.

So that I

As a developer

I want a place to credit authors so that copyright is maintained.

I also want a place to display debug information so that I can do some easy runtime tests.

This is a subtask from XXX

Time: about 3 hours

Acceptance Criteria

• Window can be presented
• Some minimum information is shown, and this includes:
  • App name (currently Steamed VPK)
  • App author (currently only kinten108101)

Commentary

This is the first time I had to dig through the source code of other projects and cross reference that with official docs.

I also came across a bug where the window is not a modal despite having been set so. This will be addressed in YYY.

As a developer,

I want a GitLab remote for my project,

So that I can enjoy some GitLab features:

• Better UI (personal preference)
• Download individual file
• Project avatar
• GNOME project branding

The GitHub remote of this project becomes a mirror. GitHub Project for this project remains. So GitHub is my dev workspace while GitLab is where I communicate with the community.

References

• Guide on new GNOME GitLab repository - https://wiki.gnome.org/Git/NewRepository
• Project requirements - https://wiki.gnome.org/Projects/Prerequisites

Commentary

I found out that for a project to be host by GNOME it must satisfy some requirements, namely that the project must have a first release. I don't plan to host my GitLab remote at anywhere that is not the GNOME infrastructure. For now, we must wait until the project is ready.

Previous endeavors have yielded unexpected AdwClamp graphics.

Turns out the form of the list came from Gtk.ListBox with the boxed-list style. AdwClamp is used to center and constraint the list.

• Implement Gtk.ListBox

UPDATE 17/04: I've also discovered Adw.ClampScrollable, which integrates Gtk.Scrollable (in our case Gtk.ScrolledWindow) into Adw.Clamp

• (CANCELLED) Update UI template to incorporate Adw.ClampScrollable

UPDATE 18/04: I'm not quite sure about the difference. And the doc said it is used with Gtk.ListView. We will pass this for now.

Resources

• Gtk.ListBox - https://docs.gtk.org/gtk4/class.ListBox.html
• Adw.Clamp - https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Clamp.html
• Adw.ClampScrollable - https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ClampScrollable.html

Acceptance criteria

• A boxed list can be made from AdwClamp

The first interface scheme did not take the download system into account i.e. I haven't paid too much thought about it. After some considerations, it seems that I need another stack page for the Downloads section.

I will also use Mod Organizer 2's add-on system i.e. separation between installed and downloaded add-ons. My original system did not consider this separation: add-on entry will simply display "installed" or "uninstalled". With that, I'll also have to update the description of the First working interface scheme task.

Acceptance criteria

• Enough mock-ups for reference (i.e. designs for the main pages)
• Static implementation
• Source code can be viewed by public
• Documentation can be viewed by public

Progress

• Mockup, see #17
• Implementation, see #26

As a developer,

I want to implement sections of my app (according to mockup) using the components from libpanel.

So that I can cut down on development time while maintaining accuracy to the mockup, and also so that I can experiment with using external libraries.

These components are:

• Panel.Omnibar
• Panel.Statusbar

Acceptance criteria

• Two above widgets are added to UI definition and can be seen.

Log

During this time I came across an issue where certain classes have not been registered. This is unexpected because I've always assumed that all concerned classes are registered during import. This led me to the discovery of the type checking method GObject.type_ensure which aims to solve this issue.

With that, I've successfully integrated the components above. However, there are some visual bugs, and these components don't appear the same as they do in GNOME Builder. It remains to be seen whether the style in GNOME Builder is custom or whether I'm not using these components in the right way.

As a developer,

I want to have a standard component organization and init flow that separate logic between aspects of the app.

So that we developers can scale the app up better.

This also affects the UI definition layout.

• Code in application.js and windows/main-window.js
• XML in UI definition

Reference

• Source code of Secrets
• Source code of GNOME Maps

1. AdwHeaderBar without window buttons. Can we customize that much?
2. GtkBox with custom style. But what about dark mode?
3. Search bar but always revealed.

I ended up with the second option. Basicallly a GtkSearchBar widget but search-mode-enabled to true. Apparently that worked.

• #25
• #23
• #33
• #32

Currently, the omni bar and the run button are grouped into one GtkBox. This, however, means that the omni bar will not be centered to the window's axis.

In GNOME Builder, a custom child type was implemented to solve this issue. This child type, right-of-center, is defined in a template header bar class. We should do the same.

Other solutions are welcomed.

Acceptance criteria

• Get the omnibar to be centered and other components stick to its sides

Progress

I found out that we can use GtkCenterBox. However, I can't use the center-widget, end-widget, and start-widget props in Blueprint. The doc doesn't mention anything deprecated. I don't know if this is Blueprint's fault or if I'm using the props wrong.

After some digging, I found a workaround. The doc mentioned two way of setting widgets to these positions.

a. Use the method Gtk.CenterBox.set_center_widget etc
b. Assign widget to the center-widget property
c. Set child with type center-wigdet etc, via GtkBuildable

I want the creation of static UI components to be decoupled from app logic so I avoided a. I chose method b but did not work. I forgot method c, and so far it worked.

This is weird. I've always assumed that you can assign things to a property both in UI template and in code.

Setup involves following this tutorial which is a "book" on GJS with GTK4.

Mock-up
Implement (static only?)

• Omnibar's body color
• Run icon's color

Estimated time

1 hour

Acceptance criteria

• Omnibar appear like in mockup and is animated properly on interaction like in GNOME Builder

I've tried to create one but it didn't work. The SVG couldn't be filtered, don't know why.

As a developer,

I want a list of features that will be necessary for the first public release,

So that I get to enjoy my product quicker and get motivated.

Also, this list should be saved in the project's Notion.

Acceptance criteria

Commentary

The final version is:

• Profile system

  • Each profile holds an add-on list

• Add-on management system

  • Add an add-on entry
  • Modify an add-on entry
  • Remove an add-on entry

• Linker system

  • Make symlinks to addons folder
  • Remove symlink

• Workshop downloader system

  • Handle download request in download queue

Set up i18n

GNOME's Blueprint markup language is more declarative, and it's easier to read through a text's nestings. I've also heard from some GNOME developers that it is more enjoyable to prototype in BLueprint. I want to try it out to see if this is true.

Blueprint's only requirement is that I must switch my text editor from Sublime Text to GNOME Builder. Indeed syntax highlighting support for Blueprint is limited throughout IDEs and text editors; I've only known Blueprint extensions for VSCode, Emacs, Vim, and GNOME Builder. During this transition, I've also made some changes to my project dependency list. See #30

Progress

• Setup so that blp files are supported
• First compile without issue
• External libraries

For external libraries to be recognized they must be pre-installed on the dev machine. Flatpak Builder do install these at build time, but only in a container, for building purpose only.

As a developer,

I want some mock-up designs for the second interface scheme,

So that I can used it as documentation material and implementation reference.

We don't have to sketch everything. Some small details and components are more easily implemented than drawn.

Final result can be observed on https://www.figma.com/file/d9rp0fXlrRxUFAHFSGDOix/SteamVpkMockups?t=yDw9SSMp7cnHXumw-1

Reference

• Review the search design pattern - https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/195
• Tentative design - https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/search/search-patterns.png

Progress

• Finish mockup frames on Figma
  • mockup AdwClamp list (see #27)
  • [CANCELLED] mockup Omni Bar Popover
• Organize frames and pages on Figma.
• Finally, update content in /data/mockups

Acceptance criteria

• Figma is presentable to the public
• Mock-up image files can be used as promo material

Other GTK/GNOME projects do this.

Currently the app doesn't work for me. Can't load my logo's svg file.

The nightly variant generated by this app is only temporarily. For a more permanent version, see #38

The current way to declare GType properties and children in JS class can be improved upon.

Recently I've come across a blog post which detailed an alternative method of declaring types for these class elements. However, doing exactly as told in this post wouldn't work, and I have made my own adjustments which still involved // @ts-ignore.

Steps to Reproduce

1. Install gtk4, libadwaita, and libpanel
2. Install NPM dependencies with yarn install
3. Generate TS definitions with yarn run build:types
4. Checkout to 54-improved-ts-integration
5. Go to /src/add-addon.ts, comment out line 9 and enable line 10.
6. Build and run the project using yarn run dev.
7. When the window appears, click on + --> "New from Steam Workshop" --> "Validate"

Expected result: no error, button shows a spinner icon and window transitions to next page.

Actual result: Validate button is frozen, an error occurs: Error: Expected an object of type GtkWidget for argument 'parent' but got type undefined

Explanation: Error is thrown at spinner.set_parent(this._validate_button); inside switchToLoadingState().

this._validate_button should not be undefined. Because it is, so spinner.set_parent(this._validate_button); returns error.

As a developer,

I want to have a medium of expression,

So that I can remind and discipline myself to be responsible of this project of mine.

• I need to keep my words straight. My stories (task descriptions) need to be detailed enough to be worth reading.

• My development speed remains low. I am totally capable of learning, but without guidance from real people it is hard to make progress. I won't get far before the school deadlines come and I must stop, as is for to my peers.

• Each day I learn something new. I usually keep that to myself (on Obsidian), but I find that boring. I started using a knowledge base with Trello because it's online-ness made me feel like I'm sending something else, even when I was not. Now it is time to make it official.

• Most importantly, I want to catch the attention of the people of the Internet. To that end, I'm planning to post daily on the fediverse. Some people there post blogs every day, and I will be no different.

Progress

Drafts are being made on Obsidian

Branch off from #17

Final result can be observed on https://www.figma.com/file/d9rp0fXlrRxUFAHFSGDOix/SteamVpkMockups?t=yDw9SSMp7cnHXumw-1

As a developer,

I want a CI solution,

So that code quality is ensured and so that PRs are treated with greater significance since they will have to pass the CI test before review could start.

Reference

• Flatpak GitHub Actions - https://github.com/flatpak/flatpak-github-actions

On the Downloads page there will be a "New" button. Clicking on it will show us a variety of options for adding a new add-on. One of that is the ability to download an add-on from Steam Workshop.

The main challenge is to only show the button at the Downloads page. Recall that the button is described in the headerbar i.e. outside of the stack page component's UI template. We should use GTK.Revealer.

A secondary challenge is to set up menu. This menu will have submenus. Clicking a command will show a modal window (for further input), e.g. a window for opening file, etc.

Acceptance criteria

• Button should appear and disappear at the right time
• Actions for each command from the button works correctly. They don't have to perform the desired action yet (i.e. processing a file after file picker window), they just have to follow a scheme. Please specify this scheme in the comment of this issue and in the PR.

We have established a UI flow for adding an add-on to the program in #25 . In this issue, we will implement the ability to add local archive into load list.
We need a tool to extract single files inside an archive. Depends on #51

• File can be anywhere (within home directory)
• Acceptable files:
  • *.vpk

As a user,

I want a popover that lists out all recent downloads

So that I can decide on

The original

• For accessibility, add options to move row up or down as an alternative to the drag handle. ¹
• Stack Page labels should be noun, not verb. ²
• (CANCELLED) Scheme changes. Each stack view should be independent and cause no side effects to each other. ³
• Remove ellipses in configure. ⁴

Acceptance criteria

• All tasks done and application can run.

• eslint (see #34 )
• prettier
• editorconfig
• lint-staged
• husky
• (CANCELLED) A module architecture in /docs

Reference

• A GTK4 project developed in JavaScript with npm packages. https://github.com/sonnyp/Commit/

Acceptance criteria

• Tools can be run
• (delayed) Integration with Flatpak (see #37 )

All modules must be specified in Flatpak manifest file. Flatpak Builder downloads all modules from specified source, then closes internet connection inside container then the internal build system starts. In the project's current implementation, NPM packages are specified in a separate file package.json, and their building process is not governed by Flatpak Builder.

Currently NPM packages aren't integrated with the Flatpak build system. This leads to developers having to manually run yarn commands and install packages before building.

But isn't this good? Flatpak modules are only used for building project, not for development. Manual module installation means that these modules are for development, which includes building. Flatpak Builder module installation means that
these modules are only for building.

Nevertheless, not all builders are developers. We should provide options.

Resources

• Flatpak tutorial on Electron apps, which do use NPM packages - https://docs.flatpak.org/en/latest/electron.html

Acceptance Criteria

• Build without using external npm/yarn commands.

I was considering making mock-up of the popover. But it does not seem to be too complicated.

Mock-up
Implement

Depends on

• #15
• #49
• #52
• #37
• #21

I am not sure how to use type_ensure. I've only seen Secrets using this feature. How to use this feature correctly? Should I type_ensure at construction of ApplicationWindow or right before a component's usage?

After a flythrough of repos, my conclusion is that:

• Most apps have their widgets type_ensure their closest children at widget init
• Small apps like Secrets type_ensure all widgets at app init.

I must document (in my personal knowledge base) all lifecycle-related methods and signals in GObject and Gio. With that knowledge, make changes in source code if necessary.

Acceptance criteria

• A rationale for writing code in each lifecycle method is available (in my personal knowledge base).

/docs should only contain relevant documentations i.e. the workings of SteamVpk.

So far, all three doc files have been about GTK usage, which is personal. In the source code, there are comments about GTK usage. Given this situation, some files have to be refactored.

The documentation locations in question are:

• /docs
• Comments

Acceptance criteria

• All documentation content are moved to the right place

Commentary

I also took the time to improve some docs, specifically Requirement Analysis.md. Now it is Overview.md and contains important information about the projects: the architecture, coding style, etc. This file, however, is only temporary. For example, the coding style section is just a reference to a Youtube video. In the future we will have better means of communicating styles, and it will have a separate file (probably through a contributor/hacking guide).

As a developer,

I want the minimum static structure (views, popovers, etc) of the app available

So that I can start developing features and see my features live (i.e. don't have to be pretty)

Components in this task should be taken from other projects whenever possible. In case when custom implementation is necessary or the use of external library is required, a dedicated task will be opened.

We should have mockups for other sections of the app. Remind you that these layouts are subject to changes, so we should not spend too much time on refinement.

Reference

• Mock-ups in /data/mockups

Acceptance Criteria

• Flow is complete, paths exist between windows and popovers as listed above.

• Components are development-ready i.e. groundwork and templates are provided in code so that functionalities can be quickly implemented.

Progress

• Main window
  • Header bar
    • Add button
    • Omnibar (Builder)
    • Notification Popover (Nautilus)
    • Menu button
      • Preference window (Bottles)
      • About window
  • Window content
    • List view (Secrets & Settings) (see more here)
  • Status bar (Builder)

History

For the main window, I prepared it with a gesture listener, a toast overlay (necessary?), and a stack system. The stack system is for preemptive purposes and may be removed in the future.

For the omni bar and statusbar, I use libpanel. Read more here.

Resources

• Overview on Wikipedia - https://en.wikipedia.org/wiki/GObject
• Overview of GLib and GObject - https://docs.gtk.org/gobject/concepts.html
• GNOME Developer Documentation - https://developer.gnome.org/documentation/

There was an issue where new windows are not modals despite having been set so.

I was trying to pinpoint the cause: action group, instantiating window, class not inheriting Gtk.Window, etc. Turns out the this operator was not referring to the class instance itself - a JavaScript problem.

As a developer,

I want to code in TypeScript with GJS

So that I can practice type safety and null safety and enjoy other niceties, such as linting from TypeScript LSP server. Also, a lot of GJS classes and methods are poorly documented. Type definitions generated from GIR files of libraries may help combat this.

UPDATE: A lot of GLib features depend on run-time glue codes. Due to this, TypeScript may not be the best choice, but we will stick to it from now on.

See #36

Acceptance criteria

• Project can be built and run using TypeScript source code.

Progress

Added new NPM packages:

• TSC
• Type definition generator from GIR files
• TS plugins for eslint

A middleware bundling system to accompany GResource. TS files in /src are compiled into /src/main.js, where GResource will take over.

Looking to try out an alternative bundling scheme (gjspack)

Clearer instructions

Depends on #37

Reference:

• https://github.com/GradienceTeam/Gradience