Panorama

[dflemstr]

Let me know what you think

Haven't had too much time to look at it, but first impressions:
I like the way you managed to make a model out of the configuration plugins, but maybe one could expose more roles somehow. The dynamic dispatch pattern would be good here (Think: double visitor pattern, or ad-hoc polymorphism, à la Haskell type classes).

So, each configuration item would have a set of "capabilities" that it supports. To name a few well-defined examples from the Haskell typeclass world:

• Bounded (Upper and lower limit defined (clockspeed, BT amplitude))
• Ordered (You can compare two items for order)
• Enumerable (You can produce a list of all items (Screen states, Wifi modes), or if you have an item, you know its successor and predecessor (int, FM radio frequencies, etc...))
• Readable (The value can be set via a String, and has a validation method to see if the input value is valid (host name, IP address, email, usernames, whatever))
• Etc... getting the idea?

One would of course use configuration-specific classes too for our situation (like, is the setting Safe to change (should it have a confirmation box or similar (CPU freq)), and does it require Elevation (root permissions), or does it consist of a Group of other settings, etc)

The widget would then adapt depending on what the configurationitem supports (Both Int and Float items are Ordered and probably Bounded, so they can basically use the same widget; if the Int item's upper and lower bounds are close, the widget might become a drop-down thing instead, since Int is also Enumerable; if there's a configuration item for cycling through WiFi modes, it too is Ordered, Bounded, and Enumerable, so the widget might make a drop-down, or, if the list is REALLY short, a cycle-button).

This might sound complex to implement, but dynamic dispatch and ad-hoc polymorphism are well-defined problems that people have already figured out (See Haskell, Java Interfaces (not really but...), Scheme, Lisp, etc) so its easy to do... Q_INTERFACES is abusable.
I'll look into this on the weekend; meanwhile, please say what you think about it.

 

[bzar]

I can't say I have a deep understanding of the concept, but I get the gist of it. Basically it would allow more free-form configuration types as they would be a collection of capabilities instead of rigid types. I can see making universally working widgets becoming more difficult, but the interface as a whole would probably benefit from the added expression power this gives to the plugins. I'd be eager to see a plan or a prototype (maybe modify the one I made?) of this kind of solution, as I have limited experience of such patterns and would like to learn more (I've been meaning to learn haskell for the better part of a decade now... always been distracted by something). In conclusion, this sounds like something we should definitely look into. I'm all for making the configuration item type system less rigid.

I could devote the next few days for bug hunting, and we'll see about this when you've had a better look and maybe put some thoughts together for the role-based approach

I looked into the git flow thing, and it seems like something I could get into. It resembles the way we do things at work, but has a couple of enhancements.

 

[dflemstr]

Fixed the controls bug, removed all warnings from pandora-libraries (That thing is a piece of HAIRY code), added a poltergeist in the code, did some UI changes.

 

[bzar]

Fixed discovering .desktop files, now finds stuff in pandora/desktop folders too.

 

[CPUnltd]

talk about fast-track development... seems like whatever problem crops up, I year "fixed!" or "found it!" the next day... crazy!

 

[bzar]

One funny thing I had to notice was that when /etc/pandora/conf/desktop (through libpnd) gives me a .desktop search path of ~/Desktop, I can't have my PND startup script set $HOME to the PNDs unionfs mount point .

 

[Esn]

Massive changes are in my Git now.

That panorama conflicts with SDL_Mixer is probably related to panorama connecting to Phonon (it *could potentially* be playing sound, therefore the library is loaded). This is an issue with the Pandora's sound mixing system (Don't you guys use PulseAudio? Doesn't the ALSA mixer work?) and not with panorama, although Phonon could probably be unloaded as a workaround.

Just in case it helps, there's some discussion going on about the Pandora's audio system in this thread.

 

[CPUnltd]

we don't use pulseaudio... more than a few people think it's a bad option to have and do not like the idea of trying to get it to work. I started a pulseaudio thread a while back to see how many people were interested in it... there were not many at all (as of now) who thought it was either worth it or that it would even function (given the "huge amount of ram" that it seems to require)... I'm still hoping for it's functionality to come to Pandora at some point. But first, we gotta fix this broken ALSA that is being used...

 

[bzar]

The issue regarding missing sound is resolved by magic in current builds. Some other change apparently fixed it too.

dflemstr: I'd like to put the PND content tree somewhere. Do you know of any good practices for sharing stuff like this that's related to the code and has some files that would benefit from versioning? Currently the PND build environment only exists on my hard drive and I don't like that. I want these out in the open .

 

[CPUnltd]

@ B-ZaR: I'd suggest using git...

git-scm.com

heard nothing but good things about it. Personally I prefer it over cvs or svn...


I believe github is a good place to host such things...

 

[bzar]

We use git already.

I meant I'm not sure putting a packaging environment in there is proper procedure. Lots o binary blobs.

 

[CPUnltd]

you can have a git repo within a git repo as a "branch" for just the purposes you speak of... I'd attended a short lecture on GIT that covered similar purposes as what you wish to do. At least they seemed similar enough for me to feel confident in what I'm saying...

 

[bzar]

I guess I could make a "pnd" branch. I'm just not really comfortable for putting the entire Qt shared libs in binary form to a version control system. Feels dirty

 

[CPUnltd]

understandable... of course, you could just create a completely separate git repo to parallel it with... even link one to the other when necessary for pulling data/configs/packages as need be... just a thought. Then you can keep the main git "clean"...

 

[dflemstr]

Submodules are your friend; you can even completely automate the builds then (see what I did with pandora-libraries). In that case, it would be nice to just add a new repo for all the files and reference it from the main project.

Otherwise; GitHub allows you to host arbitrary files along with your projects; just click on the "Downloads" button.

 

[bzar]

I was thinking of doing it the other way around, make the panorama project a submodule of the panorama-pnd project, since it's actually a part of it. This way the panorama tree stays clean of packaging stuff and git tree dependencies go the correct way. In my opinion . I'll make a repo probably today after work. I've also made a small script to handle the packaging with the help of yactfeau.

 

[dflemstr]

Yeah, it makes more sense the other way around.

By the way, I've been using clang (the LLVM compiler) all along for this project. It would obviously be preferable to use it on the Pandora for optimized builds (since it's insanely good at that), so I'll try to adapt the packaging suite for that as well, maybe (as an *alternative* to GCC of course). Here's the mkspec for clang if you're interested (just install clang and clang++ for your distro and put this in /usr/share/qt4/mkspecs; then do qmake -spec linux-clang)

I'll continue working on the panorama-as-a-qml-plugin stuff now

 

[dflemstr]

OK, done with modularization, I think you'll like the elegance of it
Pretty much requires a "git clean -dfx" (in pandora-libraries too, by the way, since I changed that too) and complete rebuild, but that's always nice to do anyways.

Also changed how SystemInformation works.

We need to change the Wiki help pages now, there are major inaccuracies.

 

[bzar]

Ooh! I'll take a look as soon as I can (just woke up, leaving for work in a couple of minutes). I like the sound of code elegance in the morning

Doing (takes a while, tens of MiBs) a first commit to panorama-pnd repo. Nothing fancy for now, jsut something that works. I had better solutions I tried first, but many of them fell to the fact that qmake mkspecs override stuff set in "parent" project files. Apparently command line trumps all, and by giving the same stuff in the qmake command they go nicely to every child project. So I did a quick Makefile to do basic build and clean. It's really hacky, but does what it's supposed to.

EDIT: Whoa that's a lotta commits

EDIT2: Halfway through reviewing your changes. I'm really liking what I'm seeing .

EDIT3: There. Reviewed. Severing pandora-libraries dependency from the panorama core by moving the pandora-specific stuff to plugins was an awesome development. When we get that one control bug out I'll package up a new PND. Awesome work

 

[dflemstr]

Seriously, you guys are still using *THAT* PND format??
And it has been extended so that it now is even MORE horrible??

I'm glad that I won't have to touch that system with a ten foot pole any more, because, man, not even the JPEG format is as bloated as the PND system.

But, err, yeah, I'll find out how to solve the focus issue...