Panorama

[CPUnltd]

would like to see documentation... plan on getting into PND packaging myself and would like to do it as efficiently as possible... so, what new features are you guys planning to bring to Panorama?

 

[skeezix]

Documentation: http://pandorawiki.org/Libpnd_hub

 

[CPUnltd]

I meant dflemstr's documentation... I'd like to see both and compare for myself... whichever I prefer, will be the one I follow...

...but thank you for the link, skeezix...

 

[bzar]

I'm planning on doing a plugin for Cloudef's MilkyHelper package manager client (adheres to the repo spec, like PNDstore). It very much resembles arch linux's pacman and seems to generally work smart. My goal here is to allow UIs to incorporate package management functions.

The details are not really clear yet, this is still mostly on an idea stage and there's so much else to do as well. I'm not going to start coding anything for this before existing stuff, like the configuration plugins and that one control bug is sorted out, but I'd like some initial comments on the subject. My ultimate goal is the possibility of making an entire pandora DE in panorama. Launching stuff, system configuration, package management.

 

[CPUnltd]

OOOOHHHH, I most sincerely look forward to seeing THAT in action... not much of a QT fan myself, but I like what is being put together here with it... I'm almost surprised that no one is attempting to work on a GTK+/FLTK/ETK equiv...

 

[Dunny]

The issue with stuff rather lies with other people that haven't been very cooperative, in my opinion (And that's all that matters for justifying my own decisions ). It has been people like CraigIX and EvilDragon that caused me trouble; CraigIX for sticking to an old version of the PND standard for a *very* long time, causing correct PNDs to misbehave on the Pandora Appstore thing (which caused a whole story on its own, because *that* had bugs too), and EvilDragon for not really having enough time to actually care about the problem, having declined multiple times when I offered to help, saying "what we have is good enough."

I realise that I'm the last person with room to talk, but the way I see it is... Fuck 'em. Pandoras are coming out, and they can put whatever they want on the firmware - doesn't mean that we have to stick to it. Hell, the GP2X shipped with a broken firmware and people came up with Open2X. Sure, people will start out with the OPT solution, but they'll soon find your "better way" and switch. Hell, at least you won't have to deal with bug reports about the stock firmware...

Personally, I'd like to see this as an integral part of Panorama, and the Pandora boot directly into Panorama. that would be way cool.

D.

 

[dflemstr]

I'll look into:

1. Making application discovery pluggable (if libpnd exists, add preview pics; if PackageKit exists, add installable apps; if pack.man. X exists, add that too... tons of plugins)
2. Adding a "Window {}" QML thing so that we can transition into doing WM kinda stuff, but I dunno how far I want to go with this (But adding a Panorama WM would be easy, with inspiration from the xmonad WM which is written in ~500 SLOC of Haskell (which is barely anything))

But I'll be VERY busy until at least the first of April, so might just do bug fixes till then.

 

[CPUnltd]

Panorama as it's own WM would be sweet! I'm sure there are simple WM backends that you can build on top of (like icewm or awesome... something like that). Something super lightweight and uncommon that can be just enough to support Panorama up to the point of being able to run on it's own above the backend (essentially, writing a script that loads whatever backend wm followed by whatever software/modules/etc required to run Panorama followed by/ended with Panorama itself loading... I'd probably suggest having all programs auto fullscreen and add in a gesture and/or hotkey to swap between running programs... you might need to build your own tool for window switching, but otherwise, this might already be doable to a degree and hacked together with a startup script... Going off my personal experience with running Compiz as a standalone WM on my Arch Linux boxes around the house (which is lightweight enough to run on a P4 with 512MB and a $20 NVidia/ATI graphics card without most of the eyecandy killing the performance)...

 

[bzar]

I'll look into:

1. Making application discovery pluggable (if libpnd exists, add preview pics; if PackageKit exists, add installable apps; if pack.man. X exists, add that too... tons of plugins)
2. Adding a "Window {}" QML thing so that we can transition into doing WM kinda stuff, but I dunno how far I want to go with this (But adding a Panorama WM would be easy, with inspiration from the xmonad WM which is written in ~500 SLOC of Haskell (which is barely anything))

But I'll be VERY busy until at least the first of April, so might just do bug fixes till then.

That first item sounds like big task. I was considering just doing a pandora-specific repo plugin, but a broader system like that would of course be better for cross-platform operation. I'm just concerned it's biting too big a chunk for now especially if you're going to be tight on time. In my opinion, one thing at a time. I throw ideas around a lot, but getting one thing done counts for a hunderd things planned.

If you're referring to my desktop environment goal with the WM idea, I was actually not referring to a WM. For as long as we're inside X we can use whatever WM is desired to window the applications. I might have chosen my words badly. I meant an integrated environment you don't need to leave to do stuff, but you can do everything inside it. We can add a task switcher without doing a new WM by accessing X's functionality. If this is the case, I think for now the configuration plugin thing is of more importance since it allows development of further functionality we can't get otherwise and is probably doable in a smaller time frame.

However, if you were planning on doing this and it was just a coincidence that I mentioned the DE, go right ahead. It would give us a better stance on running on plain X or even without X.

Oh, and how did the configuration plugin stuff go? Did you have time to think about it? I can start implementing it if you have some kind of guidelines I can try to follow. Otherwise I could just make a "preliminary" version modeled after my prototype, which we can revise when you have time again.

No pressure, take all the time you need. I'm already grateful you've offered as much to the project as you have so far

 

[Esn]

If you guys are entertaining feature requests... could there be a built-in viewer for documentation files for PNDs? This is one thing that Xfce and Minimenu fail badly at. They use Arora to open these files, and it takes ages to load; very inconvenient.

 

[bzar]

If you guys are entertaining feature requests... could there be a built-in viewer for documentation files for PNDs? This is one thing that Xfce and Minimenu fail badly at. They use Arora to open these files, and it takes ages to load; very inconvenient.

I answered your post in the other thread. I tried this but put it on the back burner for now because I couldn't think of an elegant solution to the constant mounting/unmounting. I'll probably look into this again at some point though.

EDIT: link to my original post on the embedded documentation viewer

 

[dflemstr]

If only Qt supported refcounting...

 

[skeezix]

Esn -- I'll probably improve things one of these days, just not had time yet.

The trick is that the docujmentation is either text, or html, and its within the pnd (which means we need to mount it.)

So we have to 1) mount, and 2) invoke a reader. Both take time, and Arora/Midori souck, and take too long.

My rough plan for mmenu was just to include a html->text mapping (a la "links" browser or equivilent), since it'd be near-instant to pop up the info. Or we get a fast launchign browser into the firmware, so we can use that for a reader. Thats the main startup time, laoding Arora seems to take forever.

Panorama woudl be in webkit already so it can cheat there, probably as easy as opening a QTextBrowser and pointing it at the mounted docuemntation (still have to mount, but no biggy.) Some integration would be needed there, since pndnotifyd is instructed to spit out .desktops that invoke Arora, so if they wanted to handle it specially they'd have to ignore those .desktops, and build a mount/view/unmount thing of their own. (Not too hard.)

jeff

 

[CPUnltd]

You should be able to access the contents of the PND without mounting it... there are plenty of programs out there that let you read the contents of ISOs without mounting them, couldn't something of that nature be incorporated into minimenu? Couldn't something like libmirage be incorporated?

libmirage 1.3.0-1
CD-ROM image (B6T/CCD/CDI/CUE/ISO/MDS/NRG/TOC) access library

 

[bzar]

^ how about squashfs? Many PNDs are in that format . Also I'm not really comfortable going around libpnd when handling PNDs. I don't want to invent the wheel again and risk future incompatibility.

EDIT: Also just fixed an annoying bug.

 

[dflemstr]

I worked on a libsquacc project a while ago; the idea was to provide a library for random accessing squashfs files. From the header:

#ifndef SQUACC_H
#define SQUACC_H

typedef squacc_handle_t (void *);

const char **squacc_get_decompressor_names(int *count);
const int *squacc_get_decompressor_ids(int *count);

squacc_handle_t squacc_new();
void squacc_delete(squacc_handle_t handle);

void squacc_set_squash_file(squacc_handle_t handle, const char *squashFile);
const char *squacc_get_squash_file(squacc_handle_t handle);

void squacc_set_num_processors(squacc_handle_t handle, int numProcessors);
int squacc_get_num_processors(squacc_handle_t handle);

void squacc_set_data_queue_size(squacc_handle_t handle, int dataQueueSize);
int squacc_get_data_queue_size(squacc_handle_t handle);

void squacc_set_frag_queue_size(squacc_handle_t handle, int fragQueueSize);
int squacc_get_frag_queue_size(squacc_handle_t handle);

char **squacc_ls(squacc_handle_t handle, const char *dir, int *count);

char *squacc_read(squacc_handle_t handle, const char *file, int *length);
void squacc_read_to_handle(squacc_handle_t handle, const char *file,  int fd);

#endif

Sounds interesting?

(EDIT: The project isn't done, because I didn't manage to move tons of shared state that had to be put in the thing pointed to by squacc_handle_t)

 

[skeezix]

Mounting is not too slow really (depends on Sd, but say 1/3 seconds?) when you run an app in a pnd, you dont' really notice it right?

So mostly its loading a browser and all that.. ie: arora woudl be gtk or qt based, so when firing it up all that whole subsystem has get loaded into meory and all that, big chunk; but panaorama already has all that up.

But we've had a bunch of slim browsers popping up lately, so could use some of them instead of Arora .. find a browser that starts up reallly quick and let me know; changing from Arora to somethign else is just a config file to libpnd

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=deployment/etc/pandora/conf/desktop;h=653f332ccc297e7791f9782ab33f729edc4561f6;hb=cdaa163638fe57d9616e46fbbb79d1c20090ecbb
/etc/pandora/conf/desktop

25 [info]
26 emit_info 1 # 0->no info .desktop; !0->yes to info .desktop
27 dotdesktoppath /usr/share/applications # path for pndnotifyd to spit .desktop files into
28 viewer ../../../usr/bin/arora # sh-script or prog to run. Use wrapper sh if needed.
29 viewer_args # args. <- plus filename will be passed. ie: "-a filename.html"
30 category Documentation # freedesktop standard category to use

We change that to another browser and poof, mmenu and xfce and panorama use that, magic.

jeff

 

[CPUnltd]

DEFINITELY sounds interesting... I'm sure it would have farther reaching applications beyond the Pandora, so I'd say go for it (if it would not stretch you much thinner than you are already stretched with what you are doing as of now)...

 

[CPUnltd]

Mounting is not too slow really (depends on Sd, but say 1/3 seconds?) when you run an app in a pnd, you dont' really notice it right?

So mostly its loading a browser and all that.. ie: arora woudl be gtk or qt based, so when firing it up all that whole subsystem has get loaded into meory and all that, big chunk; but panaorama already has all that up.

But we've had a bunch of slim browsers popping up lately, so could use some of them instead of Arora .. find a browser that starts up reallly quick and let me know; changing from Arora to somethign else is just a config file to libpnd

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-libraries.git;a=blob;f=deployment/etc/pandora/conf/desktop;h=653f332ccc297e7791f9782ab33f729edc4561f6;hb=cdaa163638fe57d9616e46fbbb79d1c20090ecbb
/etc/pandora/conf/desktop

25 [info]
26 emit_info 1 # 0->no info .desktop; !0->yes to info .desktop
27 dotdesktoppath /usr/share/applications # path for pndnotifyd to spit .desktop files into
28 viewer ../../../usr/bin/arora # sh-script or prog to run. Use wrapper sh if needed.
29 viewer_args # args. <- plus filename will be passed. ie: "-a filename.html"
30 category Documentation # freedesktop standard category to use

We change that to another browser and poof, mmenu and xfce and panorama use that, magic.

jeff

My thing on this part of the topic though is that you now have one more program open, even if it's just to read the documentation on a PND, it's still one more program.... meaning one more program to close AND meaning used up resources that require manually being killed (the browser has to be closed after you're done) where having something built into minimenu would be more elegant, probably lighter on resources (as it could quite literally be a colorized terminal set to fullscreen or something like that) and shut down immediately after use (by clicking anywhere on the screen or a select location on the screen... again, possibly a terminal with mouse support)... Now, in XFCE (or any other DE/WM) the browser might be ok, but I'd probably opt for a universally light solution (leading back to the colorized terminal with mouse support idea) that starts quick (1 or 2 seconds, tops) doesn't eat too many resources in general (terminal probably the lightest thing possible) and can be unintrusive whenever possible.

Just my 2 cents, hope it makes good change.

 

[dflemstr]

Also, why is the viewer hard-coded, instead of just using "xdg-open <file>"?

Anyways, will dust off the libsquacc project and work on that now, after having fixed a regression caused by B-Zar in Panorama