dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Hi Jay

I don't we fully agree on the approach yet.  Merely grouping existing
packages into smaller better defined groups was not my only intention.
I would like to propose a slightly different approach.

On top of having categories into which packages are grouped I'm also
suggesting something of a "requirement list" to which packages are
linked.  Once the user has specified his requirements you can then list
all the packages that match the requirement per category.

Let me try and illustrate:

*** Goal 1 - Natural pre-selection based on end-result ***

Let's say you have the following categories:

- IDE/Editor
- Compiler
- UI library (user interface)
- Debugging Tools

You will then have another list of requirements.  And for each
requirement there will be a fixed set of choices, e.g.

- Target environment?  CLI / Gnome / KDE / Web
- Language?            C++ / Python / Java / HTML
- Require IDE?         Yes / No
- Require Debugging?   Yes / No

Now you assign each package to category as well as link it to one or
more of the requirements.

Package        Cat       Environ        Lang       IDE  Debug
-------------  --------  -------------  ---------  --- -----
BlueFish       IDE       Web            HTML        Y    * 
Quanta Plus    IDE       Web            HTML        Y    *
Anjuta         IDE       CLI/Gnome      C++/Python  Y    *
Kdevelop       IDE       CLI/KDE        C++         Y    *
Eclipse        IDE       CLI/Gnome/KDE  C++/Java    Y    *
emacs          IDE       *              *           N    *
vi             IDE       *              *           N    *

gcc            Compiler  *              C++         *    *
gcj            Compiler  *              Java        *    *
ant            Compiler  *              Java        *    *
python         Compiler  *              Python      *    *

ncurses        UI-lib    CLI            *           *    *
qt4            UI-lib    KDE            *           *    *
GTK+           UI-lib    Gnome          *           *    *

gdb            DebugTool *              *           *    Y
valgrind       DebugTool *              *           *    Y


When you start the installer it would ask you to complete the list of
requirements.  Which you may choose to complete as follows:

- Target environment?  Gnome
- Language?            C++
- Require IDE?         Yes
- Require Debugging?   Yes

It would then present you with a list of options by category, of which
you may then select one or more:

- IDE/Editor:      Elipse / Anjuta 
- Compiler:        gcc
- UI library:      gtk+
- Debugging Tools: gdb / valgrind

So it lists by category all the items that match your requirements.

** Note **
This is how we break away from just being another
apt/synaptic/aptitude/ect... by asking the user what he wants to achieve
and then presenting him with a refined list of packages.  This is a much
more natural way of working, e.g. the way you would ask a question to
someone intelligent (e.g. mailing list): I want to do this... what is
available?

By presenting a list of packages you need to manually go to each and
match it to your criteria.  With this approach, the installer does that
for you!!!

Do you see the difference?

*** Goal 2 : Managing the environment completely ***

That is not the the end of it though.  We would now like to go one step
futher and fill in the blanks in the environment. E.g. if you have
chosen Eclipse as your IDE, you will need to be given a list of plug-ins
based on your requirements again.  Our installer will need to know this
and automatically suggest these plug-ins.  This could be defined as:

Package        Cat       Environ        Lang       IDE  Debug
-------------  --------  -------------  ---------  ---  -----
eclipse-cdt    IDE       *              C++         Y    N
eclipse-pydev  IDE       *              Python      Y    N
eclipse-gcj    IDE       *              Java        Y    N
eclipse-gdb    IDE       *              *           Y    Y

E.g. if you chose Elipse as your IDE and C++ as your language, you will
need the eclipse-cdt package which is the Eclipse C Development
Toolkit. 

The same would apply to language specific wrapper libraries for certain
packages:

Package        Cat       Environ        Lang       IDE  Debug
-------------  --------  -------------  ---------  ---  -----
qt4-python     UI-lib    KDE            Python      *    *
GTK+-python    UI-lib    Gnome          Python      *    *

** Note **
Now we not only made the selection easier, we made sure everything fits
together.  All of this saves the user a lot of time AND RESEARCH.  How
much easier would this not be for a newbie!!!


Do you see what I'm after now?

Regards
Charl


On Sun, 2009-07-05 at 05:34 +0300, Jay I. wrote:
> hi guys.
> 
> it will take me a day or two to bring the front end to some good shape
> so that we could start working on it in bzr.
> 
> now i'd like to show you some basic commands that the front end will
> support. i call it dpm. and here's a console dump:
> 
> $ dpm help
> dpm should be invoked using this format:
> 
> dpm <command> [<arguments>]
> 
> where <command> is one of the following:
> 
> help - view short description of dpm usage,
> open - open a package category,
> close - close a previously open package category,
> list - output a list of items inside a package category,
> create - add a category or package to local database,
> destroy - remove a category or package from local database,
> read - show description of a category or package,
> write - update description of a category or package,
> install - install a category or package,
> remove - remove a category or package.
> 
> you can type 'gpm help <command>' to view description of a specific
> command.
> $
> 
> and here's an explanation. first of all a (local/central) database will
> contain a treelike hierarchy of packages and package categories - much
> like a filesystem. currently dpm supports absolute paths
> (e.g. /category/package) and a subset of relative paths -
> e.g. ./category/package but not ../category/../../package.
> 
> system administrators will be free to do everything they want with local
> databases. dpm will provide a way to share some part or entire
> configuration over internet and to synchronize with our central database
> or other databases. the central database will be hosted on our website
> and clients will connect to it using a webservice. for now we will
> concentrate on synchronization and later we will talk about sharing. i
> mean if i'm an opengl guy and i know what is needed to develop opengl
> apps in c++ i could create a category '/programming/opengl/c++' in my
> local database, populate it with relevant items and share it with the
> entire community.
> 
> now back to the commands.
> 
> 'open' works much like 'cd'. it updates DPM_CURRENT_LOCATION environment
> variable which is used as a prefix for relative paths.
> 
> 'close' unsets DPM_CURRENT_LOCATION. when it's not set current location
> is '/' and relative paths are resolved relative to the root.
> 
> 'create' works this way:
> $ dpm create <name> [title=]<title> [info=]<info> ...
> 
> if <name> ends with a forward slash then it's treated as a category name
> - otherwise as a package name. i'll provide more info about available
> fields as soon as it's possible.
> 
> i think that 'destroy' doesn't need an explanation. it just deletes
> approp. record from the database.
> 
> 'read' either reads all the fields for a given <name> or if supplied by
> a list of field names fetches and displays only those. 'write' allows
> you to update either entire record or certain fields only.
> 
> 'dpm write <name> name=<new_name>' can be used to rename a package or
> category.
> 
> install/remove are quite self-explanatory.
> 
> a real-world example:
> 
> $ dpm open /programming/languages/c/compilers
> $ dpm list
> cc
> gcc
> $ dpm create mycc title="My C Compiler" info="blah blah blah"
> version=...
> $ dpm list
> cc
> gcc
> mycc
> $ dpm install mycc
> ...
> 
> current progress:
> 
> help, open, close - done.
> list - almost done.
> create, destroy, read, write - half done.
> install, remove - i will make some additional research before
> implementing them.
> 
> about downloading:
> currently all debian utilities don't provide any way to
> stop/resume/control downloading so if you're downloading your favorite
> movie but suddenly you decide to update your system you can be sure the
> the first download will either break or its speed will drop down to
> almost zero. all our front ends must provide a way to stop/pause
> downloading.
> 
> how installation works: dpm reads approp. database record, extracts
> debian repo url, downloads a package and passes it to dpkg. pretty
> simple. maybe i will use apt in some way to handle repository catalogs,
> certificates etc. this is currently what i'm trying to learn about.
> 
> conclusion:
> it's just a sketch and many things will be changed but we just need to
> start with something. so how do you like it?
> 
> regards,
> jay
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dubuntu-team
> Post to     : dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dubuntu-team
> More help   : https://help.launchpad.net/ListHelp