Author Topic: Centralized 'Best Practices' for Dingux releases (Read 6747 times)

Bouvrie · « **on:** November 05, 2009, 10:17:08 am »

I think the Dingoo community would benefit greatly from some generic guidelines for developing/publishing Dingux applications. Base for these guidelines are the currently available menu systems, DinguXMB and (the more popular) DMenu:

DinguXMB requires applications to have either .sh (shell script) or .dge (executable) extensions for them to show up in the menu. Having distinct extensions for executables makes it easier for both users and menu-like applications to identify executable files from others. Furthermore, DinguXMB allows for having a .png icon accompanying executables, which is automatically used in the menu.
DMenu on the other hand is pretty much static, although it does support having Dmenu config files per application. These config files determine how an application is added to DMenu's menu.

Based on the features of both menu systems mentioned above, the following best practices are proposed:

DINGUX APPLICATIONS

Dingux applications should be submitted to a common repository (openhandhelds, or google code for example); This would apply to their (open) sourcecode as well, so that the community can easily apply modifications to "standardize" them (i.e. changing controls, file structure and adding package scripts in time).
Dingux applications should not require user-content (like ROMs/Multimedia/Documents/etc) to be stored in the application's folder, but in a root folder. This facilitates removing/replacing/updating of the installed 'Dingux Local Pack' without actually removing user-content. That way, /local should be more confined to being for the Dinux operating system and installed applications.
Dingux applications' Control schemes shouldn't be too exotic, to allow for a unified interface when dealing with Dingux across applications. specs to be determined, possibly mimicking the Dingoo native interface.
Dingux applications should come with a predefined metadata file, with information about the application (title/developer/version/command-line parameter definition etc). specification to be determined, possibly extension of DMenu spec.

DINGUX EXECUTABLES

Dingux executables should ideally have either .sh (shell script) or .dge (binary) file extensions.
Dingux executables should ideally come with their own default icon, named like the executable, but with the icon (.png?) extension.

Note that this recommendation is purely based on the beforementioned menu systems (and their inherent features/limitations). If advances are made in the way a prominent Dingux menu system handles things, the best practices should be revisited.

zear · « **Reply #1 on:** November 05, 2009, 10:49:30 am »

Quote from: Bouvrie on November 05, 2009, 10:17:08 am

Dingux applications should not require user-content (like ROMs/Multimedia/Documents/etc) to be stored in the application's folder, but in a root folder. This facilitates removing/replacing/updating of the installed 'Dingux Local Pack' without actually removing user-content. That way, /local should be more confined to being for the Dinux operating system and installed applications.

On modern systems, updating the folders doesn't overwrite their content.
On Windows systems, you can achieve this by using programs like Total Commander.
So I'm opposed to an idea of keeping the roms in the root directory.
Besides, we're looking forward an idea of using ipkg/opkg package system instead of local packs, and that should render the replacing/updating of the apps more handy.

Bouvrie · « **Reply #2 on:** November 05, 2009, 12:16:39 pm »

Quote from: zear on November 05, 2009, 10:49:30 am

(...)
So I'm opposed to an idea of keeping the roms in the root directory.
Besides, we're looking forward an idea of using ipkg/opkg package system instead of local packs, and that should render the replacing/updating of the apps more handy.

Yeah, the package system would be much better than the 'local pack' method.

Mind you I'm not saying the roms should be in the root period. I'm saying the user should be able to pick a 'right' spot for their files, not confined to an application dir. Because aside from this 'local pack' issue, I intended the roms location to be more user-friendly: people can more easily access the roms from both Dingoo native emulators and Dingux-native ones.

Otherwise, the native emulators would otherwise require one to navigate through the whole sd://local/emulators/<emulator>/roms/<romname>, instead of just sd://roms/<romname>.

batman52 · « **Reply #3 on:** November 05, 2009, 01:46:10 pm »

@Bouvrie:
All you said make a lot of sense. I agree with you, especially about the file structure, and the control schemes. In my opinion for both of the mentioned topics, dingux should mimic the original firmware.

Quote

On Windows systems, you can achieve this by using programs like Total Commander.

I don't use windows, and I don't like to suggest using non-standard/odd tools. I am for the "Keep it small and simple" phylosopy. We can "create" our system from scratch.. why should we make it complex to manage?

Quote

Besides, we're looking forward an idea of using ipkg/opkg package system instead of local packs, and that should render the replacing/updating of the apps more handy.

That's why I wrote my how-to. Unfortunately I had no feedback from developers, and I have not the will/time to package all the available apps myself.

Quote

Dingux applications should come with a predefined metadata file, with information about the application (title/developer/version/command-line parameter definition etc). specification to be determined, possibly extension of DMenu spec.

This would be included into the control file for ipkg/opkg.

Quote

Dingux executables should ideally come with their own default icon, named like the executable, but with the icon (.png?) extension.

I agree again. Unfortunately this won't work with dmenu.

The problem is that dmenu is generally bad designed IMO: I don't see the need for different config files for every theme. It just makes it more difficult to add software, and make it crash when you wrong something (i.e. you don't have a theme-specific icon). I have shown how this could be handled with ipkg, but i am really looking forward to avoid it at all.

XMB looks better, natively embeds some useful applications like the picture viewer or the audio player, and is a more mature project, even though came to dingux later. Therefore I would not spend more time in making dmenu usable: it had his time. XMB just needs a file selector, that could be ripped off dmenu, in order to select roms to be passed to emus which don't embed a gui.
EDIT: last but not least, with dinguXMB a package manager could be not essential.

I would add to the list:
- dingux applicaitons and sources should be added to a common repository, being it openhandhelds, or a google code page, or whatever; so that the community could easily "burden the pain" of apply the modifications to "standardize" them (i.e. changing controls, file structure and adding package scripts).

codiak · « **Reply #4 on:** November 05, 2009, 02:04:20 pm »

Afaik your ipkg/opkg method works only with the linux ethernet gadget or am i wrong?
What about the Windows Users? The dont have the ability to connect the dingoo with the internet.

batman52 · « **Reply #5 on:** November 05, 2009, 02:23:42 pm »

Quote from: codiak on November 05, 2009, 02:04:20 pm

Afaik your ipkg/opkg method works only with the linux ethernet gadget or am i wrong?
What about the Windows Users? The dont have the ability to connect the dingoo with the internet.

You wrong codiak that would be an enhancement. ATM it is intended to easily install binaries that would be properly packaged into a .ipk file that you can copy int your /usr/local folder.

In this way, in order to install a package you just need to:
- copy the .ipk file on the SD
- select the "install" entry on dmenu (look at my example)
- select the ipk file to install

codiak · « **Reply #6 on:** November 05, 2009, 03:27:51 pm »

so where is the comfort? you still have to copy the file/directory.

benoitb · « **Reply #7 on:** November 05, 2009, 03:43:18 pm »

1 file to copy, no need to know where to place the icon, how to edit dmenu config files, what old files to delete, etc...
For me, it would be comfort.

batman52 · « **Reply #8 on:** November 05, 2009, 03:59:17 pm »

Quote from: benoitb on November 05, 2009, 03:43:18 pm

1 file to copy, no need to know where to place the icon, how to edit dmenu config files, what old files to delete, etc...
For me, it would be comfort.

Precisely!

It is more or less the same difference you can experience in windows between an automated installer, and pick up a zip file, extract it, copy into your c:\programs folder, and creating a desktop shortcut.

Bouvrie · « **Reply #9 on:** November 05, 2009, 04:10:19 pm »

Quote from: benoitb on November 05, 2009, 03:43:18 pm

1 file to copy, no need to know where to place the icon, how to edit dmenu config files, what old files to delete, etc...

1 file to copy doesn't necessarily make it a good thing; suppose that in an update only the executable changed but the package contains the full application with all the (multimedia) resources. Then you'd have to transfer the full package (to the Dingoo), while it only will change 1 file.

I am an advocate for keeping things simple, maintainable and as standalone as possible. Ideally, Dmenu (or any menu item) itself should be able to make sense of newly added applications, by generating a menu entry on its own, on the fly. Something the Wii homebrew channel does is perform an SD scan on startup and builds the menu dynamically. Provided the applications are self-contained (i.e. with info for menu-items/icons configured from deployment), menu systems shouldn't have a hard time dealing with them automatically.

For me personally, the power of ipkg/opkg method would be the automated update functionality. Automation is the key here. And frankly we wouldn't really need to have net access on the Dingoo; we'd just need a workstation-based application that's able to check the Internet Repository and scan the Dingoo's SDcard through USB and update the installed applications as it goes along. THAT is a very nice feature, just being able to 'sync' your Dingoo with the community, by simply running a tool.

For people reading this thread and trying to form a mental picture of how such a dedicated package repository/installer works, check out the Wii Homebrew Browser for an example (video!) of how it could work. And imagine the possibilities...

batman52 · « **Reply #10 on:** November 05, 2009, 04:49:33 pm »

Quote from: Bouvrie on November 05, 2009, 04:10:19 pm

Quote from: benoitb on November 05, 2009, 03:43:18 pm
1 file to copy, no need to know where to place the icon, how to edit dmenu config files, what old files to delete, etc...
1 file to copy doesn't necessarily make it a good thing; suppose that in an update only the executable changed but the package contains the full application with all the (multimedia) resources. Then you'd have to transfer the full package (to the Dingoo), while it only will change 1 file.

Anyway that would be a step better than a 250+Mb local package...

Quote from: Bouvrie on November 05, 2009, 04:10:19 pm

I am an advocate for keeping things simple, maintainable and as standalone as possible. Ideally, Dmenu (or any menu item) itself should be able to make sense of newly added applications, by generating a menu entry on its own, on the fly. Something the Wii homebrew channel does is perform an SD scan on startup and builds the menu dynamically. Provided the applications are self-contained (i.e. with info for menu-items/icons configured from deployment), menu systems shouldn't have a hard time dealing with them automatically.

I' wouldn't be able to implement such a thing :-( and i'm not sure of the performance. Fast boot times are a key requirement for a pmp imho. If you can, i will be grateful to you!

Quote from: Bouvrie on November 05, 2009, 04:10:19 pm

For me personally, the power of ipkg/opkg method would be the automated update functionality. Automation is the key here. And frankly we wouldn't really need to have net access on the Dingoo; we'd just need a workstation-based application that's able to check the Internet Repository and scan the Dingoo's SDcard through USB and update the installed applications as it goes along. THAT is a very nice feature, just being able to 'sync' your Dingoo with the community, by simply running a tool.

For people reading this thread and trying to form a mental picture of how such a dedicated package repository/installer works, check out the Wii Homebrew Browser for an example (video!) of how it could work. And imagine the possibilities...

I LIKE that homebrew browser! ^_^ What's wrong with having a similar app on dingoo instead of a standalone program on the desktop?

Bouvrie · « **Reply #11 on:** November 05, 2009, 07:03:45 pm »

Quote from: batman52 on November 05, 2009, 04:49:33 pm

Anyway that would be a step better than a 250+Mb local package...

I can't imagine people downloading that pack in case of updates. Basically it's a good beginner's pack, but individual apps can be added manually.

Quote from: batman52 on November 05, 2009, 04:49:33 pm

I' wouldn't be able to implement such a thing :-( and i'm not sure of the performance. Fast boot times are a key requirement for a pmp imho. If you can, i will be grateful to you!

Basically as-is now, one would only have to create a script that does this, and then configure this script to run from DMenu on demand, installing content whenever the user wants. However, the basic fact remains that in this case DMenu would call a script that would have to modify a config file (write to the SD card). The better solution would be to do an ls -R *.sh followed by an ls -R *.dge to get all the executables recursively, then load that data directly into memory. I'm not too sure about the performance though, but I can imagine performing this on load every time is slower than reading a prebuilt config file.

Quote from: batman52 on November 05, 2009, 04:49:33 pm

I LIKE that homebrew browser! ^_^ What's wrong with having a similar app on dingoo instead of a standalone program on the desktop?

Nothing 'wrong' per se with that, just some inconveniences: the SD write corruption bug, and possibly the trouble of having to configure a net connection to get the data from 'outside' sources (the zImage also requires more memory I believe).

Also, one would use the limited A320 hardware to store the resource files (on the SD), unpack the resource files (on the SD again), something which would be considerably quicker on a desktop rig in terms of processing power already. Not to mention having to free up more SD card space than required, just so both the package AND the extracted contents will fit on it.

That's just me blurbing lots of stuff, of course one can disregard them all with the argument of it looking damn good on the Dingoo when it does run from there!

Still leaves the SD corruption thing though.

Harteex · « **Reply #12 on:** November 05, 2009, 07:27:03 pm »

Quote from: batman52 on November 05, 2009, 04:49:33 pm

I' wouldn't be able to implement such a thing :-( and i'm not sure of the performance. Fast boot times are a key requirement for a pmp imho. If you can, i will be grateful to you!

Well you don't need to implement everything yourself, maybe you could work with the dmenu authors on this, or at least suggest it to them.

batman52 · « **Reply #13 on:** November 05, 2009, 08:40:59 pm »

Quote

but individual apps can be added manually

Yep, but it's so boooooooooring... in the end i basically prefer not to try any new release at all, unless it really looks good (recently it happended just with psx4all and greader2x).

Quote

Nothing 'wrong' per se with that, just some inconveniences: the SD write corruption bug, and possibly the trouble of having to configure a net connection to get the data from 'outside' sources (the zImage also requires more memory I believe).

Just a note: dingoo is already able to access the internet since it was added the ethernet gadget support!

Quote

Still leaves the SD corruption thing though.

let's hope it won't stay there forever!

vimrc · « **Reply #14 on:** November 05, 2009, 09:13:13 pm »

Quote from: batman52 on November 05, 2009, 08:40:59 pm

Quote
but individual apps can be added manually
Yep, but it's so boooooooooring... in the end i basically prefer not to try any new release at all, unless it really looks good (recently it happended just with psx4all and greader2x).

Quote
Nothing 'wrong' per se with that, just some inconveniences: the SD write corruption bug, and possibly the trouble of having to configure a net connection to get the data from 'outside' sources (the zImage also requires more memory I believe).
Just a note: dingoo is already able to access the internet since it was added the ethernet gadget support!

Quote
Still leaves the SD corruption thing though.
let's hope it won't stay there forever!

Haha, maybe we can create a sources.list for Dingux... Just apt-get it... Well, well.I know I am kidding...

batman52 · « **Reply #15 on:** November 05, 2009, 09:31:26 pm »

Quote

Haha, maybe we can create a sources.list for Dingux... Just apt-get it... Well, well.I know I am kidding...

Hopefully yes! Well maybe "ipkg install" instead of "apt-get install", but... why not?... and I'm NOT kidding...

codiak · « **Reply #16 on:** November 06, 2009, 08:34:21 am »

Quote from: batman52 on November 05, 2009, 08:40:59 pm

Quote
Nothing 'wrong' per se with that, just some inconveniences: the SD write corruption bug, and possibly the trouble of having to configure a net connection to get the data from 'outside' sources (the zImage also requires more memory I believe).
Just a note: dingoo is already able to access the internet since it was added the ethernet gadget support!

This only works on Linux

zear · « **Reply #17 on:** November 06, 2009, 09:14:35 am »

Well, who cares about windows anyway?

They still will be able to put .ipk's on the card manually.
Just go with the time guys.

DEADBEEF · « **Reply #18 on:** November 07, 2009, 02:45:38 am »

First, sorry about my broken english.

I think the ipkg system for Dingoo like this,

1. Someone hosts ipkg list on the NET. If dingoonity.org hosts the list, it's nice.
2. Write an application named "Ipkg management system for Dingoo" like "Synaptic" for Ubuntu. It read ipkg list from the NET hosted by someone, and install or uninstall the apps selected from the list.
3. Write an application named "The first install kit for PC" to using "Ipkg management system for Dingoo". "The first install kit for PC" do setting the PC to be a router for connecting to the NET from Dingoo via USB.
4. Distribute both "The first install kit for PC" and "Ipkg management system for Dingoo".
5. Once people install "The first install kit for PC" to their PC, and they install "Ipkg management system for Dingoo" to their dingoo, they can install or uninstall the ipkged applications on Dingoo which connected to the NET with USB via PC.

We care about "windows or linux" for "The first install kit for PC" only.

.....
For dmenu users only.
Make a folder to set SearchPath like "/usr/local/install".
And someone release their new apps, packing dmenu.cfg and Icon.png with their new apps.
Users unpack the apps package to "/usr/local/install/" .
When the next time starting dmenu, their application will be added automatically.

Dingoonity.org

Author Topic: Centralized 'Best Practices' for Dingux releases (Read 6747 times)

Bouvrie (OP)

Centralized 'Best Practices' for Dingux releases

zear

Re: Centralized 'Best Practices' for Dingux releases

Bouvrie (OP)

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

codiak

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

codiak

Re: Centralized 'Best Practices' for Dingux releases

benoitb

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

Bouvrie (OP)

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

Bouvrie (OP)

Re: Centralized 'Best Practices' for Dingux releases

Harteex

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

vimrc

Re: Centralized 'Best Practices' for Dingux releases

batman52

Re: Centralized 'Best Practices' for Dingux releases

codiak

Re: Centralized 'Best Practices' for Dingux releases

zear

Re: Centralized 'Best Practices' for Dingux releases

DEADBEEF

Re: Centralized 'Best Practices' for Dingux releases