Panorama

[CPUnltd]

I figure the better fix will come when you have the time to sit and actually work on it... being one who really cares about his code, I'd expect such...

 

[bzar]

OK fixed, but you will not like how I did it. There are more efficient ways of doing it, to say the least.

Reason? Lack of time...

Wow, you're right! That's one ugly hack! :lol:

...but it looks like it should work for now. I'll try it out.

 

[bzar]

Works

 

[bzar]

Uploaded new version of the PND. Remove your existing appdata before using. The PND now copies the provided interfaces to appdata so you can mess around with them . This makes the first launch take a bit longer than the subsequent ones. A whole bunch of small improvements behind the scenes, but nothing too visible. Tab switching in Tabbed currently works only through touch screen, but this will hopefully be dealt with shortly (depending on when I or dflemstr find time to look into why the trigger buttons won't work). Overall stuff is progressing at a steady pace.

 

[dflemstr]

Uploaded new version of the PND. Remove your existing appdata before using. The PND now copies the provided interfaces to appdata so you can mess around with them . This makes the first launch take a bit longer than the subsequent ones. A whole bunch of small improvements behind the scenes, but nothing too visible. Tab switching in Tabbed currently works only through touch screen, but this will hopefully be dealt with shortly (depending on when I or dflemstr find time to look into why the trigger buttons won't work). Overall stuff is progressing at a steady pace.

You need to report these bugs to the bug tracker so that I remember them <_<

Easy fix for trigger buttons committed.

 

[bzar]

Roger that. Will do from now on.

 

[dflemstr]

OK, fixed that ugly hack solution with proper code this time. Much faster, much simpler, much better.

 

[dflemstr]

The Pandora controls evdev file is being read using a different method now... This leads to the application having lower power usage, but it might not actually work on the Pandora... Testing needed, do we have a regression, or do the controls still work?

 

[bzar]

No regressions in sight after a couple of tweaks. Except in Tabbed (arrow keys on desktop), but that's my turf

EDIT: And now that's fixed too

 

[bzar]

I think we need to divide the workload a bit, since I've been meaning to fix the same things you have for at least three times now . To do this we need to think in which direction we'd like to develop Panorama. I currently have a (quite long reaching) vision of integrating more tightly to the underlying system through plugins. I'm thinking about two types of plugins: content plugins and configuration plugins.

Content plugins provide access to information without any specific way of displaying it. These are just something that the UIs can choose to include, like battery status, clock rate, wlan strength, bluetooth status and so on. When a UI is loaded it can use a global plugin manager object to request loading a plugin. A reference to the loaded plugin is returned. The plugins are unloaded with the UI. The plugins are provided with an interface to integrate with the Panorama backend.

Configuration plugins define items in a configuration item model. The items have a specific type which determines what kind of widget is used to display them, for example text, integer range, list selection or boolean. These settings can be shown using a simple View, and the control widget used defaults to a provided one, but UIs can override these. UIs can also add their own settings to the model to get UI customization. For example one configuration plugin could provide the necessary items in category Connectivity->WLAN to enable/disable wlan and connecting to a network (quite a big plugin, but should be feasible). Another configuration plugin could be used to set the used panorama UI.

I picked this model because I want to minimize the amount of broken UIs. The content plugins make sure that the UIs always have everything they need to display correctly with them. The configuration plugins separate the configuration from the views, so that a specific view does not need to "support" individual configuration options.

Crits & comments?

 

[dflemstr]

Content plugins provide access to information without any specific way of displaying it. These are just something that the UIs can choose to include, like battery status, clock rate, wlan strength, bluetooth status and so on. When a UI is loaded it can use a global plugin manager object to request loading a plugin. A reference to the loaded plugin is returned. The plugins are unloaded with the UI. The plugins are provided with an interface to integrate with the Panorama backend.

These things would be like TextFile and SystemInformation, right? We won't be able to split the Setting system from the core, but at least those other two.

Configuration plugins define items in a configuration item model. The items have a specific type which determines what kind of widget is used to display them, for example text, integer range, list selection or boolean. These settings can be shown using a simple View, and the control widget used defaults to a provided one, but UIs can override these. UIs can also add their own settings to the model to get UI customization. For example one configuration plugin could provide the necessary items in category Connectivity->WLAN to enable/disable wlan and connecting to a network (quite a big plugin, but should be feasible). Another configuration plugin could be used to set the used panorama UI.

So you mean a widget system, basically? Except that the plugin only describes how the widget should look, and doesn't get to "draw it itself?" I think that we need to define this very carefully...

So a shared library can of course contain any amount of QML resources (New definitions, new item types, etc), so that's one way of defining the interface; we let the UIs do "import Text 1.0 as Text" and then "Text.TextFile { blabla }" (Same for system information).

This doesn't really let us enumerate which plugins are available etc. though, and we'll need a different method especially for the "widget system," maybe something using our own abstract base class definition and dynamic library loading. QPluginLoader is a great help here of course...

 

[Magic Sam]

Hi guys

Thanks for your work on Panorama, latest PND works like a charm !

I have some questions for you:

- Do you think it will make it to HF6, I mean will it be possible to select Panorama as a default GUI, like minimenu or XFCE ?
- Does Panorama need XFCE to work, or can it be standalone ?
- Can we send you new / modified UIs, or is it too early ?

Bye, and thanks again !

Magic Sam

 

[dflemstr]

- Do you think it will make it to HF6, I mean will it be possible to select Panorama as a default GUI, like minimenu or XFCE ?

No clue.

- Does Panorama need XFCE to work, or can it be standalone ?

Standalone.

- Can we send you new / modified UIs, or is it too early ?

Send them, we'll add them to the source tree and upgrade them when we upgrade Panorama. It's like the Linux kernel: Everything that is in our source tree will be upgraded along with the code.

 

[Magic Sam]

Thanks dlflemstr for your quick reply !

When used standalone, for applications which are not fullscreen, which window manager will Panorama use ? XFCE's or something else ?

Bye, Magic Sam

 

[bzar]

These things would be like TextFile and SystemInformation, right? We won't be able to split the Setting system from the core, but at least those other two.

Something like those, yeah.

So you mean a widget system, basically? Except that the plugin only describes how the widget should look, and doesn't get to "draw it itself?" I think that we need to define this very carefully...

Yes, a widget system, but only for the configuration items. So that UIs don't need to implement support for specific configuration items but can still have a unified look throughout the UI. In my opinion UIs define what the configuration system looks like and the configuration plugins only define the available settings using the predefined setting types. It sounds like the cleanest solution to me.

So a shared library can of course contain any amount of QML resources (New definitions, new item types, etc), so that's one way of defining the interface; we let the UIs do "import Text 1.0 as Text" and then "Text.TextFile { blabla }" (Same for system information).

This doesn't really let us enumerate which plugins are available etc. though, and we'll need a different method especially for the "widget system," maybe something using our own abstract base class definition and dynamic library loading. QPluginLoader is a great help here of course...

Of course! How did I forget the existing QML plugin system ? Ok, so these could work for the content plugins, except for the plugin->panorama interface, but that's not the important part in them anyways. For the configuration plugins I'd like to have no changes required for UI's when new configuration plugins are added, so that definitely has to be done using other kind of plugins. I could try to wrap up an example QML plugin and draft an interface for the configuration plugins. These would be only proposals and subject to immediate dropping if better ideas arise . I'd rather see Panorama evolve towards a modular structure instead of a monolithic one, so that people can customize it to be as slim or bloated as they want without wrapping a gazillion different PNDs.

- Do you think it will make it to HF6, I mean will it be possible to select Panorama as a default GUI, like minimenu or XFCE ?
- Does Panorama need XFCE to work, or can it be standalone ?
- Can we send you new / modified UIs, or is it too early ?

- As a launcher it could be ready in time, but I for one think it needs a bit more meat before it's ready to be included in a firmware release.
- Panorama needs only Qt, which AFAIK doesn't even require X. On the other hand many of the applications do require X so it's good to have it there.
- Sure, post them here and people can try them out! Installing UIs is easy as pie, just copy them to your appdata/panorama/interfaces. Of course interfaces may change without much notice as Panorama is still in alpha.

EDIT: Ha, ninja'd by the d-man

 

[dflemstr]

So I'm unsure how one could implement this. I mean, plugins for configuration will obviously be platform-specific .so's, so it makes no sense to have them as plugins; they'll be compiled with the main project anyways. Unless we wanna enforce the loose coupling, which we can do anyways.

And how should the "available configuration 'widgets'" be exposed to QML? Remember that the language is extremely limited (it doesn't use proper JSON) so the kinds of objects you can have aren't very many.

EDIT: In b4 response

 

[bzar]

So I'm unsure how one could implement this. I mean, plugins for configuration will obviously be platform-specific .so's, so it makes no sense to have them as plugins; they'll be compiled with the main project anyways. Unless we wanna enforce the loose coupling, which we can do anyways.

Well, from the user's perspective it would allow customizing what configuration options are available. From a contributing developer's perspective it would enable users to use a configuration not included in the main tree without recompiling and repackaging the entire application every time. My two main concerns here are keeping the core lean and elegant, while not restricting users to the features the packaging developers deem good. It would also support distributed development better and speed up the adoption of new features from people "outside". One thing I like about panorama is the ease of making it your own by creating a UI without any kind of recompilation/repackaging. This would be further advanced by letting people add things they want to be configurable and share their configuration items easily.

This might sound silly, but to paraphrase my design philosophy: Panorama is already simple by default. It launches and then you run your stuff. It's very much customizable by preference. UI's can have easy customization options and making UI's altogether is easy. What's missing is changeable by design. You can't easily take a bit out and replace it wih another and have the rest of the system use the new implementation. What I'd like to do is to give the user more control over the packager.

I'm not sure if I'm putting this out right, but I hope some of the philosophy behind this is conveyed. More customizable experience for users and easier deployment for contributors of niche features.

And how should the "available configuration 'widgets'" be exposed to QML? Remember that the language is extremely limited (it doesn't use proper JSON) so the kinds of objects you can have aren't very many.

I'm seeing this being through a partial delegate. My current idea is to have a custom "ConfigurationWidget" component that instantiates the correct widget component based on a "type" property received from the configuration object and sets it as the ConfigurationWidget's child. So in the code a configuration dialog might be something like this (off the top of my head):

ListView {
  model: configurationModel
  delegate: Item {
    Text {
      anchor.left: parent.left
      text: configurationLabel
    }
    ConfigurationWidget {
      anchor.right: parent.right
      item: configurationItem
    }
   }
}

The configurationItem is of another custom type (registered to make it usable as a property) that is instantiated by the actual configurationPlugin. When a ConfigurationWidget's data changes, it changes to the configurationItem, which signals the plugin.

This is pretty much off the top of my head. I have not designed this through. But i'm thinking something along these lines.

 

[dflemstr]

Could you make some abstract classes describing the approx structure?

 

[bzar]

I can give it a shot. Might take a few days though, my pandora SD card got a corrupted partition table yesterday, so I'll do data recovery before anything else. I'll get back to you.

 

[bzar]

Got the partition table fixed, but I have so many small things brewing for panorama I'll take care of those first so I can start with the configuration modules from a clean plate.