After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 677689 - collection support
collection support
Status: RESOLVED WONTFIX
Product: gnome-boxes
Classification: Applications
Component: general
3.5.x (unsupported)
Other Linux
: Normal normal
: --
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks: 696727
 
 
Reported: 2012-06-08 10:27 UTC by Christophe Fergeau
Modified: 2016-03-31 13:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christophe Fergeau 2012-06-08 10:27:45 UTC
https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-default.png shows collections of VM which we currently don't support.
This main goal of this bug at this point is to track the open design questions related to this.
* is this collection mockup still up to date?
* do we show brokers as collections? An alternative would be something similar to http://3.bp.blogspot.com/-eon3DWJwOe4/T7zWzvs1SBI/AAAAAAAAAd0/GlDNiIy46FA/s1600/after.png
Comment 1 Marc-Andre Lureau 2012-06-08 12:42:02 UTC
Afaik, the design is similar to ios-folders. Boxes already as very basic concept of "collection tags", and I have seen Zeeshan demo already doing handling some of the UI.

Imho, it is wrong to not very friendly to show brokers as collections. Collections should be something that the user as grouped himself, not something imposed by resource/vm location.
Comment 2 Christophe Fergeau 2012-06-08 13:03:53 UTC
(In reply to comment #1)
> Imho, it is wrong to not very friendly to show brokers as collections.

Asking because the mockup has a "Boston Lab" collection, which could be a broker.
Comment 3 Zeeshan Ali 2012-06-08 13:52:01 UTC
(In reply to comment #1)
> Afaik, the design is similar to ios-folders. Boxes already as very basic
> concept of "collection tags", and I have seen Zeeshan demo already doing
> handling some of the UI.

Yeah, I got a half-baked implementation that has been put aside for a while now because of all the important bugs and would need serious rebasing as start:

https://gitorious.org/gnome-boxes/gnome-boxes/commits/collections
Comment 4 Zeeshan Ali 2012-07-03 00:33:35 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Imho, it is wrong to not very friendly to show brokers as collections.
> 
> Asking because the mockup has a "Boston Lab" collection, which could be a
> broker.

IMO, we should support both user-defined collections and also present all brokers (other than local libvirt session) as collections too. Keeping that in mind, I also agree with Marc-Andre that we should implement them as boxes as well, like I attempted to do in the rather rotten branch of mine.
Comment 5 William Jon McCann 2012-07-09 14:52:13 UTC
I tend to think of brokers as the equivalent of GOA accounts in, say, Contacts. They are sources of data rather than collections of data. The user should probably be free to organize the information as they see fit.
Comment 6 Christophe Fergeau 2012-07-09 16:46:12 UTC
Which means we should look at goa mockups for how to add/remove brokers?
Comment 7 Zeeshan Ali 2014-07-16 13:51:26 UTC
(In reply to comment #5)
> I tend to think of brokers as the equivalent of GOA accounts in, say, Contacts.
> They are sources of data rather than collections of data. The user should
> probably be free to organize the information as they see fit.

I think for VMs, it makes sense for users to know at least which ones are remote. Would be also very useful to quickly tell the host of the VMs.
Comment 8 Zeeshan Ali 2014-10-14 23:54:54 UTC
(In reply to comment #7)
> (In reply to comment #5)
> > I tend to think of brokers as the equivalent of GOA accounts in, say, Contacts.
> > They are sources of data rather than collections of data. The user should
> > probably be free to organize the information as they see fit.
> 
> I think for VMs, it makes sense for users to know at least which ones are
> remote. Would be also very useful to quickly tell the host of the VMs.

We have a separate bug for this now: bug#738554. Closing this as WONTFIX.