Talk:Task:100Days
(→Software Distribution) |
|||
| Line 55: | Line 55: | ||
:: About 2 and 3 - I thought we all agreed on that here: http://www.internettablettalk.com/forums/showthread.php?t=20261, just compiling a single list won't solve the dependency hell. [[User:bundyo|bundyo]] 19:04, 30 May 2008 (UTC) | :: About 2 and 3 - I thought we all agreed on that here: http://www.internettablettalk.com/forums/showthread.php?t=20261, just compiling a single list won't solve the dependency hell. [[User:bundyo|bundyo]] 19:04, 30 May 2008 (UTC) | ||
| + | |||
| + | :: It will not but then it is not the goal of 2. The goal is to supplement the current half-baked Application Installer app with a quickly modifiable online interface for searching and selecting applications. This will help users to find more applications and in the same time it will help developers to figure out just how exactly application installer should work. Instead of waiting for the next OS release, it is really easy to modify the web interface and see which modification is better. Later, the real App Installer can be designed to have the same or similar interface. | ||
Revision as of 19:21, 30 May 2008
Contents |
Scope of the 100 Days
Hi, just a comment: anything inside maemo.org-the-webiste fits inside the range of things that the community, the maemo.org team and myself as Nokia contact can push forward without much discussion and interference if we all agree on the appropriatness and feasibility.
Anything related to software in the platform itself (as opposed to the server infrastructure), has many other stakeholders and dependencies and therefore fall out of the scope of the maemo.org planning exercise. If you want to compile these ideas and proposals fine, but it would be really useful to keep in this page the scope on purely maemo.org, its content, processes, servers, tools... and the people collaborating around it.
More or less the same principle applies to the 2010 Agenda but in that case the discussion is more strategy and some software platform related topics might be more on topic.--qgil 13:29, 30 May 2008 (UTC)
A few suggestions for developers
A few more suggestions for developers - the bottom rungs of the ladder.
1. Validate and verify the tools installation for the current shipping version, particularly the HOWTO. I follow the instructions but nothing builds. At least until I do an apt-get dist-upgrade, update, upgrade or something similar, then apt-get the -dev versions of a half dozen things, none of which is mentioned. Which brings me to:
2. Insure the hello-world will actually build on a system cleanly installed following the exact instructions from step 1. (I had to edit things in mine) and form a deb which will work on a tablet - both install and remove. Also split out stand-alone versions to use as templates (I can't get a statusbar only version to come up as everything seems to be interdependent). Maemopad is a great write template, but a paint template (slightly more than trivial graphic demo) would be nice.
Hildon is not something I've dealt with, and has its own quirks along with GTK. They aren't bad, but I could spend a week just learning the ins and outs. But there aren't very many examples I can just change the icons and add in a chunk of code to do a simple task as a starting point, at least not without doing a lot of searching (e.g. some statusbar clocks are stand-alone).
3. Simplify the autogen/automake/autoconf stuff. Most of this will only be run under fixed releases, so the checking for some specific version of 20 libraries is redundant, and makes the build horribly complicated. Either in scratchbox things are there or not (and see #1 above if they are not! I also have to keep doing apt-gets since I need -dev of everything and often don't have them). Do I really need libtool for a trivial statusbar app?
The goal is that anyone should be able to do a working deb for a trivial off-the-cuff application or status bar, home, or control panel applet in 5 minutes by doing a global substitute (or perhaps changing a few lines of the form: #define APPNAME HILDON_HELLO_WORLD, #define AppName HildonHelloWorld, #define appname hildon_hello_world, etc.) and adding a few lines of code and scaled icons.
And for "garage", there should be one centralized repository, so there would be a "garage" parallel to "extras" with all betas and releases not higher up in the chain. Right now I've got dozens of archives and sources, so when I do a restore it becomes a nightmare getting all the applications back and it makes application manager slower having to go through dozens of archives. It doesn't help having a "garage page" if it is not much better than hosting offsite. But then for all these add-ons I could just do apt-get source and/or apt-get install. Maybe this is what "extras" is for, but it seems to never work or have anything. —Preceding unsigned comment added by 70.209.165.167 19:32, 29 May 2008 (UTC)
Mostly Technical Suggestions
Development
1. Place references / howtos / tutorials onto one page so that developer does not need to click through several menus.
2. Move outdated documentation away, but move older documentation that has not been updated for 4.x up, with a note "not fully applicable for 4.x".
3. Make it possible for logged-in developers to annotate any place in the documentation. Link to annotations from documentation.
4. Switch to SB2. SB1 is difficult to install and stays insulated from the rest of developer's system, making development complicated.
5. Provide an example of simple build environment *not* relying on AutoConf and its friends. A single includable makefile should suffice, when used with SB2.
6. Clearly *say* in the SB readme that it is not possible to debug every application on the desktop, show how to test applications on the target device using SSH/SCP or some other means.
7. Maybe provide a few simple stylesheets and JavaScript libs for creating quick iPhone-like web apps running in MicroB. This should be very light, very easy to use, and targeted to casual users.
Discussion Forums
1. Fix iTT's style sheets so that they work well on MicroB! It is a joke that a site dedicated to internet tablets cannot be effectively viewed with an internet tablet.
2. Integrate iTT with Maemo.org karma system.
Software Distribution
1. Actively hunt on the Net for maemo apps not yet added to Maemo Extras, talk to developers, ask and help them to commit applications to Maemo Extras. This especially applies to app porters currently active at iTT.
2. Use gronmayer's scripts to create a web site that merges applications from all known repositories into a single list and lets you browse them with MicroB using HTML UI similar to N-Gage, Apple Store, etc. While it sounds ambitious, it is not difficult to do, as we always have app descriptions and icons (form .deb files) and we also have screenshots for apps hosted at Garage. Reformatting this data in a format that can be nicely presented in tablet browser is not difficult.
3. Effectively replace "iTT Software Section" with #2 from this list.
- About 2 and 3 - I thought we all agreed on that here: http://www.internettablettalk.com/forums/showthread.php?t=20261, just compiling a single list won't solve the dependency hell. bundyo 19:04, 30 May 2008 (UTC)
- It will not but then it is not the goal of 2. The goal is to supplement the current half-baked Application Installer app with a quickly modifiable online interface for searching and selecting applications. This will help users to find more applications and in the same time it will help developers to figure out just how exactly application installer should work. Instead of waiting for the next OS release, it is really easy to modify the web interface and see which modification is better. Later, the real App Installer can be designed to have the same or similar interface.