Panorama

[bzar]

dflemster, nice to see you're still hanging around . I actually just got back from wars to doing panorama stuff again.

CPU, as a target I agree with that, but it's a LOT of work to get it to work like that well. I'd probably need to halt all other development for quite some time to concentrate on that stuff. I'll pick some of the lower hanging fruits first and see if I'll get to window management stuff at some point in time. No promises though, it's a bit out of my comfort zone

 

[bzar]

Stuff is happening. A lot of work to do but things are progressing steadily.
Quick preview of download queuing in Consolidation (UI based on MilkyTest, but will be more fleshed out instead of a demo )
[media]http://www.youtube.c...h?v=3fvDyBR4MV0[/media]

EDIT: that's running on my desktop, btw.

 

[milkshake]

Wow lookin good I must say

 

[fusion_power]

Looks very nice, maybe I should try Milky Test but I fear the install of the GUI, it is not included I guess and has to be done manualy. ^^""
Well, the GUI looks pretty nice, still to many colours in the overview cathegory but it's just personal taste.
The "browse/installes" lists look a little bit "dense", maybe you can alter the colour of each 2. line so it will appear as a switching between a light grey and a dark grey line for more overview? The additional lines that appear if a App is installed or updated ("3 weeks ago") are more or less confusing, you don't see if it belongs to the line above or underneeth. I would skip this line completely and add the info to another place, maybe direct in the line of the app, via a simple symbol somewhere in the line that opens a little info popup on mouseover.

However, the Download progress looks great, I miss this completely in PND_Store.

 

[bzar]

Looks very nice, maybe I should try Milky Test but I fear the install of the GUI, it is not included I guess and has to be done manualy. ^^""

In the current PND using MilkyTest requires you to just run panorama once, then edit the created configuration file in your appdata to say "MilkyTest" instead of "Test" in the interface part. Note that the UI above is not MilkyTest, even though it is based on it (so no download queues in MilkyTest).

Well, the GUI looks pretty nice, still to many colours in the overview cathegory but it's just personal taste.

Might take the colors away, since I haven't found a sensible use for them.

The "browse/installes" lists look a little bit "dense", maybe you can alter the colour of each 2. line so it will appear as a switching between a light grey and a dark grey line for more overview?

I'll try this out and see how it looks. A nice idea.

The additional lines that appear if a App is installed or updated ("3 weeks ago") are more or less confusing, you don't see if it belongs to the line above or underneeth. I would skip this line completely and add the info to another place, maybe direct in the line of the app, via a simple symbol somewhere in the line that opens a little info popup on mouseover.

Those are only visible when you set the "Newest" ordering from the category screen, the default alphabetical ordering doesn't have those. I'm not really sure how you can read them any other way than top to bottom. That kind of list is used quite a bit in several contexts, like some cell phone contact lists have headers for the first letters between the contacts. I'm confused by your confusion here . Maybe knowing that they are ordered by the time since their last update helps. The same information is also in the application detail view in the lower right corner.

 

[fusion_power]

Don't be confused by my confusion. I just have seen Videos of the Menu system, I'm sure you know better what works in practise and what not. ^^

 

[CPUnltd]

love the video! love the general idea... but piggybacking on fusion_power's idea, I'd go for the color values of 192,192,192 and 164,164,164 for the alternating shades of grey for the PND menu...

 

[bzar]

Tried Consolidation on a pandora to show off the performance difference. Worlds apart from MilkyTest

(also note the altering row colors )

 

[Schnatterplatsch]

Looks great!!!

 

[crow_riot]

respect to all the work you and dfemlstr have put into panorama! i've not had time to test it, but really i'm hoping to have this as a global addition to the desktop environments!

 

[fusion_power]

Tried Consolidation on a pandora to show off the performance difference. Worlds apart from MilkyTest

(also note the altering row colors )

Wow, impressive kinetic acceleration, looks really fast. The altering colours really improve the overview imho. This menu system really could be a important step to more userfriendliness of the Pandora. I hope we will see more usage of this in the Future. ^^

 

[dflemstr]

Just a small issue: the repo fails to build right now because pandora-libraries "ships" with its own Makefile, which makes qmake skip the pandora-libraries.pro file, causing horrific relocation errors because of libstdc++ linker stuff.

Running qmake inside of pandora-libraries fixes the issue.

A permanent solution would be to remove the shipped Makefile from the pandora-libraries repo.

Anyways, I merged all of the changes into the Panorama organization.

I'll play around a bit with the new QML stuff; I'll see what I can do. Might also do some general cleanup of all the code later (I have found some racing conditions, and some potential for decoupling, etc) if I have time.

 

[CPUnltd]

CRAZY idea just came to me! the concept of making this a standalone interface is great for down the line, but what if you started by daemonzing it and making it a dropdown "menu" (similar to how tilda, guake and stjerm are on linux distros) and tie it to the Pandora button? Then we could lose the menu bar at the bottom and have this cool interface as the "desktop menu" vs the standard setup we have now. What do you think of this idea? I'm pretty sure it would be easier to setup. Not sure about the daemonizing function, but whatever would be required to run something in the background that caused panorama to drop down and do all the cool stuff I just watched in these last couple of videos! I almost want this for my desktop too now (especially if I can get the drop-down function!!!) as this is DEFINITELY a powerful interface!

 

[dflemstr]

OK, "ported" Panorama to CMake instead of QMake.
Advantages:

• Easier cross-compilation,
• Easier distribution,
• Possibility of making Linux Desktop packages (The script currently generates .tar.gz, .tar.Z and .sh-installer files on "make package"),
• Possibility of generating .pnd files automatically (without scaffolding),
• Repo is much more organized.

EDIT: Oh yeah, and my repo is of course at https://github.com/Panorama/panorama

B-ZaR, feel free to push to that one if you want, now that I've cleaned up some of the mess

 

[CPUnltd]

NICE!!!

 

[bzar]

dflemstr, nice! I'll have to see about integrating the PND building to it, since the current PND building system I have is a real mess. I'll push to the panorama git when I have full features ready.

And for the sake of conversation: we discussed CPU's idea in private messages, and long story short: it's a nice idea, it's possible, but I'm not doing it (at least any time soon). Lots of other stuff on my plate.

 

[dflemstr]

Oh BTW: for simplicity's sake I renamed the libmilky.so (The QML plugin) to libpackages.so because it clashed with libmilky.so (The Arch/ALPM-like PND package manager) but you still load it with "Panorama.Milky"...

If it's possible to make the interface of that plugin generic enough that it could be replaced with e.g. a system based on apt or rpm or whatever easily enough (aka that it doesn't contain any milky-specific parts in *the interface*) then we could rename the QML *module* to "Panorama.Packages" as well. Might have to split the plugin or something in that case.

 

[bzar]

Guess it's possible to make it more generic. I've been working on it mainly to create UIs people can use on their pandoras up and out fast, so support for other package managers has not been an issue.

Milky-plugin's libmilky is apparently based on that libmilky, though I didn't know of that other one. There is even a pacman-esque CLI for it for pandora (milkyhelper). Maybe Cloudef will rename it at some point to differentiate from the original.

There seems to be a problem with Panorama.Applications. It takes ages to start up and even longer when an application is installed on a pandora. I traced the problem a bit, and it seems to come from ApplicationModel::dataChanged being emitted for each individual package, resulting in some processor-intensive task. My UI freezes for about a minute after installing a new PND to wait for Applications to finish. If this is I/O bound, I'd suggest threading the operation with low priority and signaling the new data to ApplicationModel after it's finished. Wanna take this or should I?

 

[dflemstr]

Milky-plugin's libmilky is apparently based on that libmilky, though I didn't know of that other one. There is even a pacman-esque CLI for it for pandora (milkyhelper). Maybe Cloudef will rename it at some point to differentiate from the original.

You misunderstand. I meant that deps/milky/libmilky.so clashes with plugins/milky/libmilky.so (now called plugins/packages/libpackages.so)

There seems to be a problem with Panorama.Applications. It takes ages to start up and even longer when an application is installed on a pandora. I traced the problem a bit, and it seems to come from ApplicationModel::dataChanged being emitted for each individual package, resulting in some processor-intensive task. My UI freezes for about a minute after installing a new PND to wait for Applications to finish. If this is I/O bound, I'd suggest threading the operation with low priority and signaling the new data to ApplicationModel after it's finished. Wanna take this or should I?

A thread is way overkill for that I think. If the problem is that the model is being updated too often for the initial data load, then we'll just tell the model once that the data has been updated, after all the applications have been loaded the first time. This is fixed in this commit.

Also you seem to have copied a lot of code to the milky plugin from the applications plugin. That code will need the same fix; or just make a library out of the shared code or something.

 

[bzar]

You misunderstand. I meant that deps/milky/libmilky.so clashes with plugins/milky/libmilky.so (now called plugins/packages/libpackages.so)

Right.

A thread is way overkill for that I think. If the problem is that the model is being updated too often for the initial data load, then we'll just tell the model once that the data has been updated, after all the applications have been loaded the first time. This is fixed in this commit.

It's not that the model is updated too often, it's that it takes too long. When a watched directory is changed (PND is installed/removed), the UI freezes for over a minute. By following the activity in the applications plugin after installing a new PND with a bunch of debug logging I noticed the execution of the "emit dataChanged" line takes 1-2 seconds. Also for some reason this 1-2 second delay happens for almost every PND, even those not changed. Same with the startup: the initial model building is a significant portion of the total startup time. Your new fix should help with this part, but I think the problem is deeper. What slot is called on the dataChanged signal that takes 1-2 seconds? Why are non-changed desktop files processed on rescan?

Also you seem to have copied a lot of code to the milky plugin from the applications plugin. That code will need the same fix; or just make a library out of the shared code or something.

Yeah, mostly the filtering part and a skeleton for the other stuff. The same thing does not seem to be a problem in the milky-plugin, since the model is reset from libmilky's data every time a change occurs, so there's no flood of dataChanged on init, and only beginResetModel/endResetModel stuff when running.