Release Panorama

[bzar]

Funny, I thought about adding this to my previous post, but decided against it, because you already wrote that you like your things seperated.


I'm not quite sure if it would be practical (especially when there are few pnds installed and the repo has 200+ apps), as I fear that the installed pnds will perish among the not installed.


So the "all time right" solution would be to make it optional.

This is exactly why I like them separate. Also the use-cases are different in my mind.

A basic question that came to my mind:


Is it possible (with a reasonable amount of "sweat") to implement a "dashboard" like user interface? It does not need to be very fancy, just something where you can arrange several "smart panels", like a clock, a weather indicator, system info indicators, etc (they don't have to be movable, arranging them via qml -or a configuration file would be enough). Or would that require some reworking of the basic structure of panorama ? While I'm at it : How about more than one "desktop" - like modern cellphones have - to which you can easily switch by pressing the shoulder button / swiping with the finger / moving the mousecursor to a screenborder ?

It is possible. I contemplated on making a carbon copy of windows 8's panel view at some point it could use separate QML files to specify panel-style widgets that show specific things, and the panels could be made full screen by clicking. Of course any complex stuff (like fetching weather info) would require doing a small QML plugin in C++, but simple stuff like a clock or showing web content would be easy to implement in pure QML.


The desktop swithing is possible and already showcased in dflemstr's "Test" UI.

Last but not least: As I'm belonging to the minority that isn't really comfortable with using nubs as mouse, and rarely uses the styles - please keep it all keyboard - managable :unsure:

That's the plan. I'm a fan of using the game controls as well, but touch screen gives nice eye candy for videos

 

[thatgui]

dflemstr's "Test" - UI was the main source for the idea, but I wasn't sure wether it was only an abandonded "first draft" (because it lacks functionality) or still stands for the current posibillitys.


Sounds very promising - all I have to do know is shovel 8GB free diskspace :blink: on my hd for installing the qt sdk - to play a little with qml

 

[bzar]

You only need 8GB if you install all the cross-compiling environments (symbian, maemo, meego harmattan...). In linux you can just install the Qt libs and QtCreator+QMLViewer in a few dozen megabytes and be done. I'm sure something like that is also possible on windows (I presume), but for obvious reasons I have no idea how

 

[bzar]

dflemstr's "Test" - UI was the main source for the idea, but I wasn't sure wether it was only an abandonded "first draft" (because it lacks functionality) or still stands for the current posibillitys.

Oh, and all the UI stuff is pure QML magic. Panorama merely offers data models (like application information, packages, battery state, pandora controls, settings), services (like executing applications, installing packages, or setting volume) and an execution context for QML documents.

 

[bzar]

New video! Pandora controls

https://www.youtube.com/embed/-I_PnRTdDNk?feature=oembed

 

[thatgui]

No more teasing please, give us something to play with :rolleyes:


I do have some thoughts:


- Major feature for me would be the ability of selecting several pnds (via checkboxes or something) for installing/uninstalling


- I would prefer a more simplistic category list - I don't see any benefit (except that it seems more finger friendly), but lengthens the navigation process, and diverts my eyes more than it helps them to "navigate" through the list


- The security dialog preceeding the install/uninstall (for me) optically seperates the acknolegdement from the application, how about leaving the background as it is (showing the milky backend)?


- I could not see (or did i miss it?) a dialog for choosing the target location for pnds - how is this handeld


- Just out of curiosity - why did you chose the milky backend over the pndstore backend ?


btw. is there a x86 build of panorama ? It's a little bit cumbersome to play with the qml file on the pandora - preferably for Windows (as I'm currently bound to it - at least for the next two weeks )

 

[bzar]

No more teasing please, give us something to play with :rolleyes:

As soon as it's feature-complete (doesn't mean finished )

- Major feature for me would be the ability of selecting several pnds (via checkboxes or something) for installing/uninstalling

Supported by the plugin, not implemented in MilkyTest UI, because it aims for simplicity of use, good usability, and relatively low development overhead compared to the plugin. Nothing stops other UIs from implementing support for this. Just adds complexity.

- I would prefer a more simplistic category list - I don't see any benefit (except that it seems more finger friendly), but lengthens the navigation process, and diverts my eyes more than it helps them to "navigate" through the list

Could you elaborate on this? What kind of list would you consider better? I chose the grid style because it shortens the path from any given category to the next, reducing the amount of required key presses.

- The security dialog preceeding the install/uninstall (for me) optically seperates the acknolegdement from the application, how about leaving the background as it is (showing the milky backend)?

I want to grasp the user's entire attention with that dialog. Since it's modal, the user can not interact with the rest of the UI when it's visible anyway, so I decided to make it so that the user is not confused or distracted by the rest of the UI when he can really only interact with these two buttons.

- I could not see (or did i miss it?) a dialog for choosing the target location for pnds - how is this handeld

Not yet added. Will be located in the bottom bar.


EDIT: also it is possible to set these from Panorama's settings file, but I intend to add widgets to select them from the UI as well.

- Just out of curiosity - why did you chose the milky backend over the pndstore backend ?

Libmilky is a library. Pndstore is an application. To use pndstore I'd had needed to first make it into a library. Also libmilky is more featureful.

btw. is there a x86 build of panorama ? It's a little bit cumbersome to play with the qml file on the pandora - preferably for Windows (as I'm currently bound to it - at least for the next two weeks )

It wouldn't be hard to do an x86 build (I use one all the time when developing), but a windows build could be a bit more difficult since some of the plugins depend on linux stuff. A linux build is just a matter of downloading the git and doing "qmake CONFIG+=debug; make" once you have the few necessary build tools like Qt development packages.

 

[Tempel]

- Just out of curiosity - why did you chose the milky backend over the pndstore backend ?

Libmilky is a library. Pndstore is an application. To use pndstore I'd had needed to first make it into a library. Also libmilky is more featureful.

To elaborate: pndstore_core is a library. But as a Python library, it may be difficult to incorporate in non-Python applications. And yes, many people around here, like Cloudef, are more competent than I, so libmilky is likely the better choice. I'm even considering eventually turning PNDstore into a frontend for libmilky, sometime after Cloudef creates Python bindings for it. Or maybe other competent people like B-ZaR will make frontends so good that they can supersede PNDstore, and I can retire it .

 

[bzar]

^ Right. My bad

 

[Christoph.Krn]

- I would prefer a more simplistic category list - I don't see any benefit (except that it seems more finger friendly), but lengthens the navigation process, and diverts my eyes more than it helps them to "navigate" through the list

Actually, when using the physical gaming buttons, the navigation process can be potentially shorter in a grid compared to a list. Getting to any object that lies in a grid potentially requires less input than getting to any object that is in a list. However, a GUI is not just about input, and the reason for why the difficulty of navigating the current grid is higher than the difficulty which most people experience with average lists is that there are some things about this grid which make it especially hard to keep an overview.


Here are some likely reasons that I can see for why this is happening:

• There is no unconfusing way to quickly hop in and out of the grid (this does not confuse, but makes the user press a button twice (opening, later closing), which sometimes can have quite a negative impact on the subjective speed of the navigation process).
  
• The colors of the buttons seem to be random - do they serve any specific purpose that I don't see? If not: often, it's better to assign colors to buttons based on some kind of carefully sorted out meaning. A very simple example for this would be if all categories that contain applications which can be used for working had one color, all categories that show multimedia software had another color and so on.
  
• It's not obvious that the grid can be scrolled, and the user has no idea at which part of the grid he is looking and how big or small the full grid is. Possible solutions to this can be to put in a scroll indicator, or at least make the lower half of the lowermost buttons disappear off screen so as to give the user a clue.
  
• With so many options of equal importance next to each other, it's sometimes a good idea to create some kind(s) of option(s) that stand out as having a higher "importance". For instance, by creating a "Multimedia" button for all ~multimedia categories, or by putting all these ~multimedia categories under a "Multimedia" headline (the option of skimming through the headlines would then have a higher "importance", or potential benefit, than the option of skimming through the buttons).
  

-----

- The security dialog preceeding the install/uninstall (for me) optically seperates the acknolegdement from the application, how about leaving the background as it is (showing the milky backend)?

I want to grasp the user's entire attention with that dialog. Since it's modal, the user can not interact with the rest of the UI when it's visible anyway, so I decided to make it so that the user is not confused or distracted by the rest of the UI when he can really only interact with these two buttons.

If possible, the modal dialog should be avoided, but if you are going to keep it in, you should put in any kind of activity (ideally, progress) indicator if an operations takes longer than some seconds to prevent that users may think that something just froze.

 

[Blue Protoman]

Skeezix must be hiring somebody to kill you by now.

 

[sebt3]

Skeezix must be hiring somebody to kill you by now.

He hired me, but he only offered a beer and dont pay for the flights... So not going to happen soon.


/me is wondering if he did that on purpose ?

 

[bzar]

There is no unconfusing way to quickly hop in and out of the grid (this does not confuse, but makes the user press a button twice (opening, later closing), which sometimes can have quite a negative impact on the subjective speed of the navigation process).

Yes, pressing the R trigger in category view returns the user to the browsing mode. But I see the problem. No idea how to hint it effectively though.

The colors of the buttons seem to be random - do they serve any specific purpose that I don't see? If not: often, it's better to assign colors to buttons based on some kind of carefully sorted out meaning. A very simple example for this would be if all categories that contain applications which can be used for working had one color, all categories that show multimedia software had another color and so on.

No real function yet, they are generated based on the category name, so the same category always gets the same color. I considered doing some sort of color coding to the package entries using those colors. Dunno if I will. Manually assigning colors based on some sort of grouping could be a nice touch, like based on what menu they'll go into.

It's not obvious that the grid can be scrolled, and the user has no idea at which part of the grid he is looking and how big or small the full grid is. Possible solutions to this can be to put in a scroll indicator, or at least make the lower half of the lowermost buttons disappear off screen so as to give the user a clue.

Absolutely true. I'll tune the item height so that this happens.

With so many options of equal importance next to each other, it's sometimes a good idea to create some kind(s) of option(s) that stand out as having a higher "importance". For instance, by creating a "Multimedia" button for all ~multimedia categories, or by putting all these ~multimedia categories under a "Multimedia" headline (the option of skimming through the headlines would then have a higher "importance", or potential benefit, than the option of skimming through the buttons).

I've planned a feature like that, and also adding your own categories. Neither of these is a priority though. The MilkyTest UI is mainly the UI I use to test milky-plugin, the plugin that provides Panorama UIs with package management features. I didn't at first intend it to be actually used by anyone, but as there seemed to be intrest toward it, I thought I'd polish it up a bit. So basically it's showing all the categories that the repo JSON mentions, so I see that the plugin works right. If there will be people using it, I'll make it better

If possible, the modal dialog should be avoided, but if you are going to keep it in, you should put in any kind of activity (ideally, progress) indicator if an operations takes longer than some seconds to prevent that users may think that something just froze.

I've tried to do that in some places, like downloading. The dialogs are pretty snappy except for that part, with little delays from key press to view change. An exception is the "installing" part after download, where the downloaded file is copied from its temporary location to the target directory. I could add a spinner there to show it's not frozen. Usually it doesn't take long, but for big PNDs it might. I'll have to test it.

 

[thatgui]

Could you elaborate on this? What kind of list would you consider better? I chose the grid style because it shortens the path from any given category to the next, reducing the amount of required key presses.

Just a simply list for the slower ones like me-> my eyes get distracted when they have to "cross" borders where different colors meet, specially when it comes to two axes (x and y). As of that I loose the "overview" with the current list, thus making navigation slower for me.


So just a list where all categories are orderd in a vertical fashion, with no color differentiation would be the easiest for me. Maybe it could be pimped a little by placing sub categories horzontal next to the main category, so I'll have an 'anchor' on left to orientate.

I want to grasp the user's entire attention with that dialog. Since it's modal, the user can not interact with the rest of the UI when it's visible anyway, so I decided to make it so that the user is not confused or distracted by the rest of the UI when he can really only interact with these two buttons.

For me it's already done by placing the dialog at that apparent location.

It wouldn't be hard to do an x86 build (I use one all the time when developing), but a windows build could be a bit more difficult since some of the plugins depend on linux stuff. A linux build is just a matter of downloading the git and doing "qmake CONFIG+=debug; make" once you have the few necessary build tools like Qt development packages.

Understandable to bad my two weeks off are still two weeks away (I can't fix my linux installation till then, right now im stuck with Windows <_< )

 

[bzar]

^ Could be, could be. For now I just want to get this thing out of the door . Let's discuss this again when people have actually used it. Not brushing this off, just more productive for me at this point to concentrate more on getting the thing ready for release than to redo already working stuff . The UI is easy to customize if you want some part of it a bit different.

 

[bzar]

Uploaded Panorama 1.268~bzar (went with dflemstr's random version pick, couldn't think of a reason why not ) to the repo.


New stuff:

• New Qt plugins (like JPEG support)
  
• Milky-plugin package management plugin based on Cloudef's libmilky backend library
  
• MilkyTest UI to try milky-plugin out with
  
• Several smaller changes (like moving libpnd support from static to dynamic loading)
  

Remember to delete your old appdata to get the new UI!

 

[bzar]

Added a video that shows usage from the top, right after you first launch the MilkyTest UI.

https://www.youtube.com/embed/pA8OB9K_1wE?feature=oembed

Also, could a mod change the thread title to just "Panorama" since I still post the updates here? Thanks

 

[Cloudef]

Heh, It looks great already.

 

[bzar]

A small update of requested features on milky-plugin and MilkyTest:

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

milky-plugin:

• New libmilky and libpnd, now with less memory leaks!
  
• Support for finding out if packages have been modified in the repo since last sync
  
• Support for getting modified date and package size in a human-readable format
  

MilkyTest UI:

• Ordering packages by "last modified" date (latest changes on top) or alphabetically
  
• Filter /mnt/utmp and /mnt/pnd from devices
  
• Crawl device on startup and device change
  
• Sync button is disabled when there's no new stuff in the repo (checked at startup, device change and every 5 minutes)
  
• Show package size, current repo version, installed version and last updated in package details
  
• Don't start loading icons if the package list is moving
  

Now back to doing wars-gamenode

 

[thatgui]

Hi,


any chance you could provide your testbuild for pcs?