From: David C. <dav...@gm...> - 2010-06-06 01:53:29
|
Hello people, I will be making some progress in the mingw-get GUI in the following git repository: http://github.com/dacap/mingw-gui Anyone have some idea of how the GUI should look? For example, 1) the first screen should ask you for what subsystem you want to install/manage (mingw32, msys), e.g Status Subsystem Path ------------------------------------------ Installed mingw32 C:\MinGW Installed mingw32 C:\MinGW-testing Installed msys C:\msys [New] mingw32 [...] [New] msys [...] 2) second screen, you can select what action we should do for each package. Status Package Description ------------------------------------------ Not-installed binutils ... Installed gcc ... [Update] c++ ... [Remove] ada ... ... 3) third screen, you see the download/installation progress. |
From: Charles W. <cwi...@us...> - 2010-06-06 17:21:13
|
On 6/5/2010 9:53 PM, David Capello wrote: > Anyone have some idea of how the GUI should look? I think there were a number of mockups (ascii art and the like) that have been posted over the last year or so. But you probably already know about those. > For example, > 1) the first screen should ask you for what subsystem > you want to install/manage (mingw32, msys), e.g > > Status Subsystem Path > ------------------------------------------ > Installed mingw32 C:\MinGW > Installed mingw32 C:\MinGW-testing > Installed msys C:\msys > [New] mingw32 [...] > [New] msys [...] I dunno. One thing that's currently being discussed is the fact that, at present, the "Developer ToolKit" actually includes both components that are in the "msys" subsystem, and components that are in the "mingw" subsystem. So, if I wanted to install the DTK, the installer would simultaneously need to know where *both* subsystems were installed, not just one. To solve this problem, the installer probably needs to parse all of its manifests, itemize how many subsystems are represented, and dynamically update this screen to allow the user to choose the appropriate directory for each of the subsystems represented (where 'disabled' would remove any packages in that subsystem from subsequent screens). Or, we could split the DTK into two separate parts, an MSYS piece and a MinGW piece, which would each be installed separately during two different executions of the installer. See that other thread for more discussion, I suppose. -- Chuck |
From: Keith M. <kei...@us...> - 2010-06-07 18:03:14
|
On Sunday 06 June 2010 18:20:44 Charles Wilson wrote: > On 6/5/2010 9:53 PM, David Capello wrote: > > Anyone have some idea of how the GUI should look? > > I think there were a number of mockups (ascii art and the like) > that have been posted over the last year or so. But you probably > already know about those. It is expected to closely follow the model established by synaptic: http://www.nongnu.org/synaptic/action.html but with the flat categories list, (in the left-hand pane), replaced by a tree view generated from the package-group-hierarchy specified in the download manifests. I've already provided a wx-widgets based prototype for this, and John E provided a native w32api adaptation. > > For example, > > 1) the first screen should ask you for what subsystem > > you want to install/manage (mingw32, msys), e.g No. There is no need for this. Users will simply select a package from the list, (in the top-right pane), to see the description in the bottom-right pane; right-clicking on the package, in the top-right pane should offer a context menu, from which install/upgrade/remove actions may be scheduled. Each package is explicitly associated with a subsystem, so there is no need for users to select that separately. The entire concept of "first screen", "second screen" ... is flawed, IMO; all operations should be driven from one top-level window, with menus providing access to options or configuration dialogues. > > Status Subsystem Path > > ------------------------------------------ > > Installed mingw32 C:\MinGW > > Installed mingw32 C:\MinGW-testing > > Installed msys C:\msys > > [New] mingw32 [...] > > [New] msys [...] The package list pane, in the top-level window, should present a columnar list, with headings "Package" (content is the fully qualified form of the package name, i.e. subsystem-name-component representation), "Installed Version" (obvious content, blank for packages not installed), "Repository Version" (obvious content) and "Description" (content is the text of the "title" attribute in the "description" element of the XML package declaration). Each row should begin with an iconic representation of installation status. We may consider adding further columns later, but for now, there is no infrastructure in place to support any. > I dunno. One thing that's currently being discussed is the fact > that, at present, the "Developer ToolKit" actually includes both > components that are in the "msys" subsystem, and components that > are in the "mingw" subsystem. > > So, if I wanted to install the DTK, the installer would > simultaneously need to know where *both* subsystems were installed, > not just one. To solve this problem, the installer probably needs > to parse all of its manifests, itemize how many subsystems are > represented, and dynamically update this screen to allow the user > to choose the appropriate directory for each of the subsystems The CLI installer already *does* parse all available manifests; the GUI variant should do likewise. Subsystems are identified in the system-map section of the var/lib/mingw-get/data/profile.xml file. Users should *not* be permitted to add or remove a subsystem *definition*; (those are specified by the package maintainers). However, we could provide a mechanism, via a "Settings" or "Options" menu, which allows them to add or remove their own named system-map specifications, (including their subsystem associations), and to select an alternative active system-map; (they should not be permitted to remove the default system-map). > represented (where 'disabled' would remove any packages in that > subsystem from subsequent screens). At start-up, the package list should show *all* available packages, ideally in alphanumerically sorted order. If users want a more selective list, they may select any of the category groups in the tree-view, (in the left-hand pane of the main display), to filter out those packages which lack an affiliate specification for the selected category, or any of its children; (neither my prototype, nor John E's IIRC, included the package affiliations for child groups, but I think development should progress towards that objective). There is no need, even conceptually, for a disabled subsystem, beyond filtering out packages specific to any subsystem which is not associated with the active system-map. > Or, we could split the DTK into two separate parts, an MSYS piece > and a MinGW piece, which would each be installed separately during > two different executions of the installer. I don't see how that would offer any benefit. -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-06-08 18:37:37
|
On Sunday 06 June 2010 02:53:22 David Capello wrote: > I will be making some progress in the mingw-get GUI in the > following git repository: > > http://github.com/dacap/mingw-gui Ultimately, anything you contribute will have to make its way into our CVS repository. It's obviously your choice, how you progress your own work, but would it not make more sense to work with that directly? -- Regards, Keith. |
From: David C. <dav...@gm...> - 2010-06-09 03:57:21
|
First of all, thanks to Charles and Keith for the replies. I will be reading your mails and making some progress with the prototype in the next days. [continue below] On Tue, Jun 8, 2010 at 8:31 AM, Keith Marshall <kei...@us...> wrote: > On Sunday 06 June 2010 02:53:22 David Capello wrote: >> I will be making some progress in the mingw-get GUI in the >> following git repository: >> >> http://github.com/dacap/mingw-gui > > Ultimately, anything you contribute will have to make its way into our > CVS repository. It's obviously your choice, how you progress your own > work, but would it not make more sense to work with that directly? Sincerely, yes, it will make more sense to work directly in CVS, but in practice I prefer to use Git until the first stable release (because I can add/remove files and refactor code more easily, I can make micro instantaneous commits, etc). Good bye |
From: David C. <dav...@gm...> - 2010-06-09 03:59:05
|
First of all, thanks to Charles and Keith for the replies. I will be reading your mails and making some progress with the prototype in the next days. [continue below] On Tue, Jun 8, 2010 at 8:31 AM, Keith Marshall <kei...@us...> wrote: > On Sunday 06 June 2010 02:53:22 David Capello wrote: >> I will be making some progress in the mingw-get GUI in the >> following git repository: >> >> http://github.com/dacap/mingw-gui > > Ultimately, anything you contribute will have to make its way into our > CVS repository. It's obviously your choice, how you progress your own > work, but would it not make more sense to work with that directly? Sincerely, yes, it will make more sense to work directly in CVS, but in practice I prefer to use Git until the first stable release (because I can add/remove files and refactor code more easily, I can make micro instantaneous commits, etc). Good bye |