Pandora Usability of package management (PND) --> Coordinating related development efforts

[porg]

This memo concerns

• Thinkers who oversee the Pandora software platform as a whole and on the long run (core team & others)
  
• Plus in particular the developers of:
  Launchers like: MiniMenu, XFCE Menu, quick text based launchers
  
• Package managers like: PNDStore, Panorama Milky test
  
• Package metadata/override editors/tools (PND and OVR)
  

Topic of this memo


Software packages are at the center of the Pandora, hence the overall way how to manage them are key to success of the platform's usability and popularity.


Currently the different aspects of managing and using PNDs are spread over a patchwork of different tools and workflows, and some aspects are yet not covered at all.


I now try to describe what is important from a user's point of view, what already exists (to my knowledge), what should be realized, and point towards possible gap-closing and synergies between existing solutions.


Disclaimer: Generally speaking, the patchwork per se is nothing bad. Openness is the principle of the Pandora, and it should by principle be always possible for a tool to cover/handle just a very small and specific task. Nevertheless from the user's perspective it is appreciated to have as little steps as necessary for common tasks in (at best) one uniform environment.


Follow up


This topic consists of many aspects, which themselves again are complexly inter-connected. It is discussed here within this thread, taking advantage of the notification system, quoting possibilities, etc, BUT the important outcomes, milestones, etc shall please be added and looked up in a structured form at the wiki page http://pandorawiki.o...gement_workflow

 

[bzar]

I'll add some comments later today regarding panorama and milkytest.


EDIT: What is the preferred format for comments? I used a simple


Comment here - <username> <UTC timestamp>

 

[porg]

@B-ZaR: Great that you joined in, as you are part of the concerned audience, because of PanoramaMilky.


All: If necessary mark your additions with author and date as YYYY-MM-DD [hh:mm UTC] meaning the date part always, the time part optionally, and if you state it, then as UTC.

 

[Caine]

I'm not the biggest fan of wiki-based discussion, but we'll see how it works out.


Is there any way to easily insert those timestamps automatically?

 

[porg]

Use the signature symbol or insert the markup yourself.

Addition One --~~~~

: Nested addition Two --~~~~

:: Deeper nested addition Three --~~~~

 

[milkshake]

I dont understand the relevence of discussion within a wiki? I mean this is what forums were designed to handle is it not? I thought wiki's were for information gathering/storing.

 

[Caine]

I dont understand the relevence of discussion within a wiki? I mean this is what forums were designed to handle is it not? I thought wiki's were for information gathering/storing.

Yes, I agree with this.

 

[porg]

OK, let's discuss single/overall aspects here. BUT then please add the summarized single outcomes / agreements / gathered info in a structured form to the wiki, that those who then work on this large issue (coming from here, or joining at a later time!), have everything structured at one place, rather than scattered among multiple quotes and replies.

 

[Caine]

Agreed. We'll update the wiki whenever open issues get resolved.


So, one issue I briefly addressed on the wiki is regarding your notion of tagging. Could you clarify more clearly what you mean with it and how you expect this to be utilized by GUIs?


My initial assumption is that you mean assigning one or more (user-defined) keywords to an application such that those can be used later for e.g. searching. The only place to currently store such tags is in the three override notes (I think). However, those note fields have no semantics and therefore tools cannot interpret them reliably.

 

[porg]

I used the word "tagging" in its broadest meaning. To add "all kind of metadata" to an item, such as categories, alternative names.


I did not think about "tags" in its meaning as "freely assignable terms" (free vocabulary).


Changed the wiki paragraph accordingly.


So for the beginning having the possibility to mass edit the EXISTING (specified) meta data fields would be very fine!


A new thing such as tags, could be a cool thing. But better not in the "custom note lines", but rather in a specified field, in order to maintain order and standards.

 

[milkshake]

also in regards to tags what is stopping people from using some obscure tag? maybe if this is something that happens moving forward the only people that should be tagging them are the devs themselves?

 

[porg]

Milkshake, I did not understand your sentence semantically. Please rephrase.

 

[milkshake]

sorry I was reffering to:

"freely assignable terms" (free vocabulary).

and how we would enter them in a maner what would prevent people adding obscure random tags for which has no corralation to the PND/APP

if we were to use them.

 

[Caine]

and how we would enter them in a maner what would prevent people adding obscure random tags for which has no corralation to the PND/APP

The only tags, in the traditional sense of the word, currently available are the categories. It is already possible to set arbitrary values in there, though they are not supported equally as those defined by the freedesktop menu standard.


[edit]


A quick mockup. This is not in any way an existing project but rather an impression of how software could possibly be adapted to accommodate these concepts.

Taking PNDstore as starting point. I added in two preview pictures of the selected application to enhance the discovery process of finding relevant software. The white pane would contain the same content as PNDstore currently does.


There should probably be a URL to the repository or a panel or sub-window to show a description. But, keep in mind, screen space is extremely limited.


The Install button is replaced by an install or run button depending on local availability of the application. A filter/search bar is added to quickly search for an applications name or category.


An adaption of the OVR editor is integrated directly into the tool, allowing direct overriding of categories, titles, notes, etc..


Is this the kind of integration you had in mind?


Question: does the repo spec provide an API for fetching the ratings? If so, those could be added in a column of their own.


[/edit]

 

[porg]

Dear Caine: Basically, yes, this is the way to go!


But before you put too much effort into further developing your own app, really have a look at B-ZaR's Panorama in Milky mode (

https://www.youtube.com/embed/_fjZ-JWTOIk?feature=oembed).

PanoramaMilky: It already has a lot of what we want, and according to B-ZaR's feedback on the repo and youtube the milkytest backend supports even more, which is yet not used (parallel downloads, download in the background while UI remains responsive to new input, etc). And it looks so wonderful, and uses the Pandora input keys so nicely. It already implements "overview" very good (just type text right away, and it is used as a name matching filter, and various sort and filter options exist). "Launch" can be added quite easily I guess. "Tag" might not be its scope, certainly not "mass tagging", possible one day


Now more into detail concerning Caine's mockup presentation:


If the application stays open and keeps its state, after the newly tested app returns, then this setup as presented on your mockups is very well suited for "discover, install & test/run, tag, keep/remove". It should also remember its last display state for the next program launch. These small details save a lot of time for the user (not navigating over and over again each time). User friendly while saving RAM when not needed!


And besides this single editing mode, I still would love to see one "mass editing" mode, "spreadsheet-like", you know, we spoke already.


It should be possible that one can select multiple items at once, and change certain of their fields at once (i.e. you put two formerly subcats together by selecting items of both subcat "old-A" and "old-B" and then changing them to "new-A".


Certain filter and sort functions are nice too.


If vertical scrolling should get necessary, having the option to freeze the name column and the header rows, helps to always properly associate cell content.


In order to not re-invent the wheel: Possible one can take a spreadsheet/database editing app, and modify it to our needs, or even leave a spreadsheet application as-is, and build a bridge inbetween:


1) A scanner could parse the PND and OVRs and scrape everything together, save it into a spreadsheet document.


2) Then you edit the spreadsheet document as you are used to, with all its abilities. You save and close the file.Tell our bridge program "I am done".


3) Then it parses the spreadsheet and translates the changes back into the OVR files.

 

[Caine]

Dear Caine: Basically, yes, this is the way to go!


But before you put too much effort into further developing your own app, really have a look at B-ZaR's Panorama in Milky mode (demo video).

Your link is broken, but I'm familiar with the app. I didn't have any actual plans to develop this (unless there is a high demand for it), I just quickly merged the user interface files of the OVR editor and PNDstore (both are built using glade).


[edit]

https://www.youtube.com/embed/_fjZ-JWTOIk?feature=oembed
Yes, that's actually planned. The challenge is to avoid lots and lots of scrolling. Don't know how to tackle it best yet, but I will figure out something. By the way, that mockup does not exclude batch modifications (you could have multiple selections active).

 

[porg]

Agreeing with all your statements!


What do you think about the variant "PND+OVR <- bridge -> Spreadsheat editor" ?


Yes scrolling has do be dealt with for sure. That's why having some features as column/header freeze on/off can surely help.

 

[Caine]

What do you think about the variant &quot;PND+OVR &lt;- bridge -&gt; Spreadsheat editor&quot; ?

I don't think it will save much work and has less control than a dedicated app.

 

[porg]

Interesting to read that, as I expected the effort balance to be different.

Btw, after I assigned custom personal sub-categories to some games, I just discovered a new MiniMenu bug! Reported it right away:


MiniMenu: Flawed tab display of sub-categories if they have a common string beginning

 

[Caine]

Btw, after I assigned custom personal sub-categories to some games, I just discovered a new MiniMenu bug! Reported it right away:


MiniMenu: Flawed tab display of sub-categories if they have a common string beginning

I'm not surprised. Those categories are violating the freedesktop menu specification standard. XFCE would place them all in the submenu "other". As I said above, you can do it, but you will not get the same level of support from launchers as the standardized categories do.


[edit]Hmmm, yes. That's indeed rather odd behaviour.[/edit]