one click to create an image

Asked by Eric

I've search through the questions in this site and not getting the desired answer. so I create this post and hopefully there is a way to configure cubic to the way that fit my workflow. cubic is awesome.

After the initial build of the first ISO, all the subsequent changes to the image are 1) the version number, 2) the chroot env

1) i rarely change the version number until the current customization is done.
what is considered done is that making all the changes, output iso, test it with VM.
so the version number does change but not frequent

2) the chroot. this is the place i change every single time to add stuff and install package.

is it possible to configure cubic so that
1. don't ask the working folder everytime the cubic start
2. straight to the chroot env
3. one click to build the final ISO (with optional button of field to change version number)

4. (HOPE!). able to run cubic in CLI environment.

Question information

Language:
English Edit question
Status:
Answered
For:
Cubic Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Cubic PPA (cubic-wizard) said (last edit ):
#1

1. Don't ask the working folder every-time the Cubic start

Someone else also asked for this. The proposal was that Cubic would default to the folder for the previously worked-on project. In order to do this, I would have to store some (minimal) state information in the user's ~/.config directory. Currently, I do not do this, because I didn't want to create hidden files on the user's system. Currently, everything Cubic needs is stored inside the project folder (so it is not "hidden" from the user).

Nevertheless, this looks like something people are interested in, so I will see what I can do. (It would have to be in a future release, of course).

2. Straight to the chroot env

If I implement the default project directory in #1, I would still want the user to land on the "Start" page and have the option of picking a different project directory or creating a new project. There is a lot of setup work that happens on the "Project" page (the page that lists the parameters for the original ISO and the custom ISO). Every page in Cubic does something important, such as error checking. I tried to minimize the number of pages and steps as much as possible.

For example, you may have noticed, after you pick a *.iso file to customize, it takes about a quarter second for all of the fields to populate on the "Project" page. That's because there are a bunch of values that get "computed" on that page, and these values are needed later on when the custom ISO is generated. So the application would still have to go through steps performed on the "Project" page in order to get to the "Terminal" page, even if we didn't show page(s) before the "Terminal" page. In Cubic, the "Project" page essentially initializes all of the values for the rest of the steps.

3. One click to build the final ISO (with optional button of field to change version number).

After the "Terminal" page, there is a "Prepare" page. This page looks at the changes you've made on the "Terminal" page ("chroot") and figures out things like which kernels are available, and how to generate the package manifests. So, we still need a step that does this analysis, whether or not it is shown on a page in Cubic. it just makes sense to show some processing steps to the user, so the user doesn't think the application crashed or hung. Keep in mind, different people have different hardware, and some people still use pretty outdated CPU / Memory / Disk to run Cubic. So we need to give some visual feedback to the user about what is happening.

4. (HOPE!). able to run Cubic in CLI environment.

Cubic is a GUI application. Years ago, I started out with a bash script that would do (some of) the things Cubic does. However, half way though the generation process, I would realize I forgot to make one small change in the "chroot" environment. The only way to fix this would be to Ctrl-C the script, and literally start all over again. This was frustrating. I wanted a way to be able to go back to the chroot environment to make a quick minor change, and not loose all of my work (and time). So I created Cubic as a GUI app to allow this. Cubic is designed as a GUI application, and it is multi threaded (unlike a script) so the user can interrupt the overall process at any time and navigate back and forth. It wouldn't be possible to translate this into a CLI application at this point.

However, I will keep this suggestion in mind for the future.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

These are all good suggestions. I'll see what I can do about #1, and I will keep the others in mind as I add features and make changes to the application. Thanks for sharing your thoughts.

Revision history for this message
Eric (erickwokck) said :
#2

1. Don't ask the working folder every-time the Cubic start

If not storing the last session info in the user home, I think it may make sense to create a command-line option, not a full CLI capability but a switch to specify the startup folder. So that user can create their own cubic_project1.desktop file for specific cubic working directory. It may also be an option somewhere in GUI to export such proj.desktop file so that the subsequent work on that will start with it. Think it may avoid the concern of having a hidden file because it is done intentionally by the user and it will not limit the usage to only the last project or the default project.

2. Straight to the chroot env
I agree that having the start page that allows users to define all the necessary parameters of the project is important. I am just thinking that after the initial setup, I would rarely change them again except the version number and the chroot env. Understand that the collection of the necessary data for computation of the project is essential for the later steps, however, I found that there is not much interaction needed with those values from the user point of view and the only thing to me is to click the next button to proceed. The preseed/boot page is usually only required once during the initial project setup unless the focus of the customization is really about the boot parameter. If users found that all the subsequent steps are no change to be made, would it make sense to have a button like “straight to build iso” and letting all the steps and the next page running in the background?

3. One click to build the final ISO (with optional button of field to change version number).

Agree. Although Cubic does work flawlessly for me and I need need to deal with any error since I start using it. It is a great piece of software.

4. (HOPE!). able to run Cubic in CLI environment.

I really appreciate the creation of this software and have no intention of asking for changing its trajectory. To me, the current GUI approach makes the building of custom ISO easy especially for a user like me who is not have much experience with all the commands for building/compressing/packing to make a bootable image. At least to me, the CLI way is more about reducing the operation to a single click or command. It would be extremely useful when there are things that fail after the customization and repeating the build by changing a very tiny bit of the system.

Can you help with this problem?

Provide an answer of your own, or ask Eric for more information if necessary.

To post a message you must log in.