dubuntu-team team mailing list archive

[Ryan Macnish <nisshh@xxxxxxxxxxx>]

Ah yes i get it now Charl, now that you have explained it, it does make alot more sense. That really works because all the new users can use our installer and prevent questions in forums like "What IDE is best for C++?" and so on, whereas more advanced users may choose to just use synaptic, because they usually know exactly what they want.

> From: charl.wentzel@xxxxxxxxxxxxxx
> To: jay.27182818@xxxxxxxxx
> Date: Mon, 6 Jul 2009 21:07:43 +0200
> CC: dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Dubuntu-team] cli frontend
> 
> 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
> 
> 
> _______________________________________________
> 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

_________________________________________________________________
POP access for Hotmail is here! Click here to find out more
http://windowslive.ninemsn.com.au/article.aspx?id=802246