GNOME Bugzilla – Bug 758128
Refactor wizard source page into its own class
Last modified: 2018-01-11 10:28:38 UTC
This is the first step to solve https://bugzilla.gnome.org/show_bug.cgi?id=750784
Created attachment 315623 [details] [review] wizard-source: Take bounding box from Wizard This moves the box containing the WizardSource out of the Wizard class and into WizardSource. This change is needed to make the Wizard class simpler and to ease its port to GtkAssistant.
Created attachment 315624 [details] [review] wizard-source: Don't access wizard window This makes the WizardSource class more self-contained by adding the file_chooser_requested() signal and the select_file() method to remove the need of accessing the wizard's window. This change is needed to make the Wizard class simpler and to ease its port to GtkAssistant.
Created attachment 315625 [details] [review] Rename WizardSource to WizardSourcePage This change is needed to keep the wizard's pages' name consistent.
These commits are the same as found in https://bugzilla.gnome.org/show_bug.cgi?id=750784 but updated and fixed.
Review of attachment 315623 [details] [review]: ACK still
Review of attachment 315624 [details] [review]: ack
Review of attachment 315625 [details] [review]: If it's the same, still ack.
Well keeping in mind that WizardSource was already a separate class, I don't think these changes are independent enough to be merged separately from rest of the changes in bug#750784, I don't see why you put these changes into a separate bug.
The whole refactoring is quite big and I unfortunately don't have that much time to spend on it, especially if I regularly have to solve conflicts from changes included in master every time I want to work on it. I think that splitting the wizard's refactoring into several smaller bugs, one per page, would allow to merge the changes little by little into master: from the first page to the last one so the order of the changes would follow the order in which the data in processed. The first page is that one that need the least changes, hence it clearly isn't the best example. I think doing so would make the whole refactoring process easier, but I could totally understand if you don't what this to happen as it would introduce partial changes into master. Any thoughts?
(In reply to Adrien Plazas from comment #9) > The whole refactoring is quite big and I unfortunately don't have that much > time to spend on it, especially if I regularly have to solve conflicts from > changes included in master every time I want to work on it. > > I think that splitting the wizard's refactoring into several smaller bugs, > one per page, would allow to merge the changes little by little into master: > from the first page to the last one so the order of the changes would follow > the order in which the data in processed. The first page is that one that > need the least changes, hence it clearly isn't the best example. > > I think doing so would make the whole refactoring process easier, Yes, I can understand how it'll help you but there hasn't been any major changes in git master since 3.18 and there won't be any to cause any major rebasing for you. > but I > could totally understand if you don't what this to happen as it would > introduce partial changes into master. Yeah, I wouldn't want partial changes. I would advise you to instead to keep rebasing your changes on git master every week or so (put it in your calendar perhaps). That way, even if you won't have time to work on it, you'll mostly have small rebasing to do, you'll remain in touch with code. When you do get time to actually work on it, you'll be able to start immediately rather than dealing with large rebase or figuring out what were you going for.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/74.