dubuntu-team team mailing list archive

[jay <jay.27182818@xxxxxxxxx>]

hi charl

the trick is that different desktops use different theming mechanisms.
for example if you run a qt based app in gnome it will use its own style
- not the one specified in desktop preferences. you may try to install
some qt based program e.g. okteta and see how it works. also every
control looks and feels different in every desktop even if they use
similar themes. generally we will benefit from moving all gui related
code to a separate library caz this will make the rest of the code less
sensitive to changes in gui. it will be possible then to create gui in
say ogl or direct3d or anything else without any changes to the rest of
the project. also we will have a core separated from gui so that it will
be more reusable.

yesterday i saw a link to that article on wikipedia. i didn't expected
that someone had already used 'scm' somewhere. okey, lets call it
package manager for now. i think we should use some descriptive name so
that it wouldn't make any confusion for a newbie.

i'm not against bzr but i'll have to learn it and test at localhost. on
the other hand anjuta has good support for cvs/svn, not for bzr. just
search for 'bazaar anjuta' in google. many projects for ubuntu are
developed using svn so maybe it's worthwhile using it too. at least svn
is definitely more popular than bzr.

okey let's play with all this stuff for some time. lemme know when
you're ready. let's first try to make some very simple program together.
for example i'll create a program that displays a window with one button
and you will make a patch to add another button or so. just to make sure
everything goes fine and solve as many problems as possible right now
before we start making something serious.

best regards,
jay


On Thu, 2008-12-11 at 12:32 +0200, Charl Wentzel wrote:
> Hi Jay
> 
> I don't think we'll actually need to separate the GUI code either.  Of
> course I'll have to read more up on GTK, but I believe it's also
> independent of the desktops.  I'm not aware of of programs that use
> GTK (such as GIMP) that has separate versions for each desktop.
> 
> In fact it may even be platform independent (as in OS independent).
> The selection of tools is such that if Windoze used packages we could
> have run it on there as well! :-)  But that may just destroy our
> project :-D
> 
> Good!  Then we start with the Configuration Manager.  However, the
> concept "software configuration manger" or SCM is well know and used -
> refer to Wikipedia.  It covers a different aspect of what we're trying
> to do.
> 
> Package Manager is the name used to describe Apt, Adept, Kpackage,
> Synaptic and Kynaptic.  Why don't we just call it "pacman".. oops! I
> think its taken! :-D  (To be honest I never really enjoyed Pacman that
> much.  I wonder how many people still remember it?)
> 
> I think we should call it the Package Manger for now, while we think
> of a name.
> 
> Regards
> Charl
> 
> 
> 
> -----Original Message-----
> From: jay <jay.27182818@xxxxxxxxx>
> To: charl.wentzel@xxxxxxxxxxxxxx
> Cc: Dubuntu - Ubuntu for Developers <dubuntu-team@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Dubuntu-team] package selector for devbuntu
> Date: Thu, 11 Dec 2008 10:41:52 +0200
> 
> hi charl
> 
> well, maybe we could put aside devbuntu for a while... maybe its
> worthwhile to create the installer first?
> 
> i think it's time to start our glossary. lets use the word installer to
> refer to an os installer i.e. a program that installs an operating
> system. this chunk of software will be out of our scope for a long time.
> what about the configuration manager, how will we name it? just
> 'Software Configuration Manager' may do but many other meaningful names
> are possible. so what you think? maybe we shall give it a proper name
> like Synaptic or Adept? 
> i agree with your definition of subdistro.
> 
> a word about platform independence. the only things we will depend on
> will be gtk+, apt and mysql (i don't mention must-be things like
> gettext). apt exists on every platform. in future we could support other
> databases. what about gui, i suggest to move all gui code in to a
> separate library and create versions of this library for every desktop.
> thus the program will have the same look and feel as others on the same
> system.
> 
> best regards,
> jay
> 
> On Thu, 2008-12-11 at 09:16 +0200, Charl Wentzel wrote:
> > Hi Jay
> > 
> > Regarding the "sub-distro".  I agree that we should at some point have
> > a full distribution.  All I'm saying is  let's focus on the installer
> > first. At least up to the first major release.  Once we have a
> > successful installer and we have captured peoples interest we can take
> > it further.
> > 
> > The major problem with issuing a sub-distro is the existing desktop
> > variations, i.e. Ubuntu (Gnome), Kubuntu (KDE), Xubuntu (Xcfe), etc.
> > Development guys work on every platform so we can't exclude any
> > specific group.
> > 
> > The road map as I see it is the following:
> > 1. Alpha releases
> > - Full working version of the installer only
> > - Including a few "sample" mega package definitions
> > - No actual packages included in the download
> > 
> > 2. Beta releases
> > - Update version of the installer
> > - Hopefully a whole lot more mega packages (depending on
> > participation)
> > - A trail downloadable CD with the installer and all packages on the
> > CD
> > 
> > 3. First major release
> > - Same as Beta release... just better.
> > 
> > 4. Next major release
> > - Subdistros for each desktop?
> > 
> > 
> > But I'm beginning to think that two separate projects is the way to
> > go, as we have two different agendas here:
> > 
> > a. the installer
> > Create an installer that may replace Synaptic and other package
> > managers/installers.  The ultimate aim to allow for complete
> > sub-distributions to be created.  This is obviously the key to success
> > and may even be more successful than Devbuntu, because of its wide
> > scope and what it will enable others to do.
> > 
> > b. Devbuntu
> > A sub-distribution for development using the installer.  Initially in
> > the shape maga-packages, later on a full installation.  This is where
> > there is scope for a subdistro.
> > 
> > Maybe it's better to keep it one project for now and split it later.
> > What do you think?
> > 
> > 
> > It is clear that the installer will have to be truly desktop
> > independent to be a success.  Probably one of the problems with Adept
> > and Synaptic is that they are the preferred package managers for
> > either KDE or Gnome... I think... I better check my facts.
> > 
> > Regards
> > Charl
> > 
> > 
> > -----Original Message-----
> > From: jay <jay.27182818@xxxxxxxxx>
> > To: charl.wentzel@xxxxxxxxxxxxxx
> > Cc: Dubuntu - Ubuntu for Developers <dubuntu-team@xxxxxxxxxxxxxxxxxxx>
> > Subject: Re: [Dubuntu-team] package selector for devbuntu
> > Date: Thu, 11 Dec 2008 03:26:41 +0200
> > 
> > i agree with your idea of installer. but anyway we'll have to make a
> > pure devbuntu distro because not everyone will like to first install a
> > number of packages during general installation of ubuntu/kubuntu/xubuntu
> > and then delete/replace them as it's time consuming and our goal is to
> > save users' time as well. and you will also have to use two cd's instead
> > of one. for newbies it will be much easier to install an integrated
> > distro that will carefully guide him/her through the entire installation
> > process. but it's not something of great importance so we can safely put
> > it off until we're done with the configuration manager.
> > 
> > 
> > 
> > i've suggested to replace synaptic because it's the configuration
> > manager whose job is to extend current configuration. if you want to
> > manage entire configuration from one place then you either use synaptic
> > or scm - not the both. if the configuration manager is capable of adding
> > new packages to existing categories and creating new
> > mega/metapackages/package categories it will provide a great way for
> > users to share their configurations in form of patches for existing
> > megapackages or as brand new ones (in form of XML or JSON files; i stand
> > for JSON as it will save traffic (and thus time) still remaining human
> > readable, and will simplify online editing with javascript). if we
> > implement it carefully there will be a boom of new subdistros and
> > everything else as everything that you need will be a preinstalled
> > configuration manager and our website or any other site with a
> > compatible web-service. our role in this process will be to approve some
> > of thirdparty patches and create new ones to keep the official selection
> > up-to-date. but everyone who won't agree with us will have enough
> > freedom to create an alternative solution. what about synaptic, afaik,
> > it doesn't use any 'pure' database like mysql, but scm will use a such
> > so the entire synchronization between the two can be implemented just as
> > dumping scm database into synaptic's configuration files (maybe to apt
> > ones as well). i guess it won't be too hard (we could implement it as a
> > plugin for example; maybe we'll make another plugin that will import
> > current configs into the database as a separate megapack or such).
> > if i get it right we have most of synaptic's functionality implemented
> > in apt libraries so we really shouldn't avoid replacing it. today
> > synaptic is not the best thing one can imagine as a package manager - it
> > 'thinks' too long because it doesn't use any pure db like mysql, it
> > doesn't allow bittorent or other download managers to survive while it's
> > doing its job as it doesn't have anything like a pause button. if we
> > succeed we will provide users with a more user-friendly tool that will
> > allow you to manage your configuration from one place (with synaptic you
> > still need to add repos via another program). finally as we are free to
> > implement anything in scm we will be able to make it embeddable into
> > another gtk based apps like ubuntutweak or such making the invention of
> > a 'pure' control center for ubuntu more feasible. in short, if
> > everything goes fine we will bring software management process to
> > another level while staying compatible with the whole ubuntu world.
> > 
> > 
> > 
> > > I do wish to keep the more detailed selection feature as this allows
> > > the pros (whom most of the time are very "picky") to customise the
> > > selection more.  This is an optional step which will only be suggested
> > > for Pros.  And only at this stage do you get to save your selection.
> > 
> > > If we use a logically managed process with a description of each step,
> > > the newbie will learn how and why everything is done.  He would learn
> > > something as he goes along.  This will be much faster and more
> > > organised that the University of Google.
> > 
> > installation process will start at megapackage level and go down to the
> > package level so even pros will have entire freedom of choice. maybe
> > we'll provide them with a synaptic-like look at the list of available
> > packages so that they'll just pick up some packages they're aware of
> > instead of searching for a certain catergory these packages belongs to.
> > but this can be implemented as a plain search function - nothing
> > complicated when you use mysql. by the way here's a simple scheme of
> > possible ui:
> > 
> > ______________________________________________________
> > |                    |                                |
> > | navigator:         |  list of package categories:   |
> > |                    |                                |
> > | list of megapacks  |  [x] compilers                 |
> > | developer studio   |  [ ] ide's                     |
> > | >> cli development |  [x] documentation             |
> > |____________________|________________________________|
> > |                                                     |
> > | [save]               [root][previous][next][finish] |
> > |_____________________________________________________|
> > 
> > the navigator column shows how far from the root you are at the moment.
> > every item in it is clickable so you can move to any upper level
> > instantly. in the 'list of package categories' you are shown what
> > categories belong to 'cli development' metapackage and in which ones
> > you've installed something. next/previous/finish buttons implement a
> > step-by-step approach desirable for newbies and annoying for pros. also
> > we'll add a special area for descriptions of every step that will guide
> > newbies.
> > btw. adding a package that's not selected by us yet will be as easy as
> > adding it's name, version, repo (an apt line) i.e. everything needed to
> > install a package with apt. and you most probably won't have to type it
> > in as scm will provide you with an autocompletion feature.
> > bookmarking feature can be used to save you current position.
> > 
> > 
> > 
> > i also think that blueprints will help us but we must first clearly
> > outline some basic concepts they will reflect. by the moment we only
> > have a concept of installer. well, let's add an approp. blueprint. how
> > to add them by the way? i'm very new to launchpad.
> > 
> > 
> > 
> > what about gui development - almost the only thing i didn't try on
> > windows was mfc. i had a very big experience in gui development
> > including everything from writing gui apps in MASM and other assembly
> > flavors to playing with .net classes in c# and vc++. but on linux i only
> > worked with xlib and never touched gtk. so i'll have to learn it too.
> > i guess at this point we can make some general decisions about what
> > common ide to use, what repository to use and where to store it.
> > any ideas on a public repo are welcome as i won't be helpful here. i
> > guess an svn somewhere at sourceforge will be enough. what about ide -
> > i'm currently using netbeans (switched to it from eclipse) but i guess
> > anjuta is more approp. for us:
> > http://anjuta.sourceforge.net/features.
> > http://ubuntuforums.org/showthread.php?t=295515
> > i'll give it a try on these days. eclipse and netbeans are also capable
> > of building gtk+ apps but if we decide to use glade we'll have to use it
> > as a separate tool when anjuta natively supports it.
> > 
> > 
> > 
> > what about the name, Software Configuration Advanced Management sounds
> > like we already have working Software Configuration Management. let's
> > first implement the latter;-). i agree that we need a fork here -
> > installer and configuration manager should not be linked too tightly (in
> > fact the installer will only need to invoke the manager after the first
> > reboot). this will make it possible for other guys to easily port scm to
> > another platforms.
> > 
> > best regards,
> > jay
> > 
> > On Wed, 2008-12-10 at 06:53 +0200, Charl Wentzel wrote:
> > > Hi Jay
> > > 
> > > Thanks!  I think we're getting to the real nitty gritty now... that's
> > > great.  And of course the more thorough we are at this stage, the less
> > > problems we have later on.
> > > 
> > > 1. The installer
> > > We don't have a lot of time to get the first version out if we want to
> > > stick to the Ubuntu schedule, which is in line with my thinking as
> > > well.  The whole Ubuntu world is synchronised, we shouldn't be the odd
> > > ones out.
> > > 
> > > To reduce the work and make things even simpler I suggested the
> > > installer with no general Ubuntu installation, i.e. you install
> > > Ubuntu/Kubuntu/Xubuntu/etc from the normal installation CD's, Then you
> > > run our installer to install your development environments.  This is
> > > the same approach taken by Edubuntu, which simplifies things a hell of
> > > a lot.  
> > > 
> > > It also means there are a lot of things we won't have to worry about
> > > and the users can get the benefit of all the effort and features put
> > > in by these respective Ubuntu versions.  I believe it will create a
> > > much bigger audience for us as most people want to use and experience
> > > the "natural" releases of Ubuntu and only wish to customise it to
> > > their needs.
> > > 
> > > Of course, where then left with testing our installer on the
> > > pre-release versions of these sub-distros, which would be a lot less
> > > work.
> > > 
> > > This also take care of your comment regarding not having a filing
> > > system to "save" your selection in, as you will be working from a
> > > fully operational Ubuntu system by the time you start this installer.
> > > 
> > > There will then be only one program (one installer) that will take
> > > care of everything:
> > > - whether you run it immediately after installation, 2 years later on
> > > an old installation
> > > - whether you want to make a clean minimalistic install or update your
> > > already highly customised installation
> > > Installation and upgrade would be the same process.  And only one
> > > installer means less work for us.
> > > 
> > > Ulitmately, we could release a full sub-distro for development, for
> > > those who want it, but I don't think it would be as successful.
> > > 
> > > Again to simplify things, I don't wish to replace things like
> > > Synaptic.  It's a good thing, it works well and is well integrated
> > > into Ubuntu.  Anyway it is very handy in selection packages that are
> > > not included in our "selection".  It also takes care of the upgrading
> > > of individual packages which I think is outside our scope.
> > > 
> > > The function of our installer for now should be to simplify selection
> > > of packages.
> > > 
> > > 2. I agree with your vision of the package selector and we'll probably
> > > have plenty more discussions on this matter.  I think to simplify this
> > > work, we need to create a blueprint on launchpad or use the existing
> > > blueprint by Brad Whittington (would you mind Brad?).
> > > 
> > > I do wish to keep the more detailed selection feature as this allows
> > > the pros (whom most of the time are very "picky") to customise the
> > > selection more.  This is an optional step which will only be suggested
> > > for Pros.  And only at this stage do you get to save your selection.
> > > 
> > > I think, we're missing each other on the "configuration management".
> > > I don't which to "create" packages or meta-packages inside the
> > > installer, i.e. specify new things for inclusion.  What I meant was
> > > saving your detailed selection.  You will only be able to select that
> > > which is available for selection.
> > > 
> > > Does this make more sense?  The actual "creation" of the available
> > > selection is what the development team is there for, that's us.  An
> > > trust me, this will require a lot of late nights as it is!!!!
> > > 
> > > 3. On the process of selection... I think the "process management"
> > > concept is probably better that my "questions" concept.  If you ask
> > > someone a bunch of questions and then provide the answers, you've
> > > simply fed them with a spoon and they are no wiser.  If we use a
> > > logically managed process with a description of each step, the newbie
> > > will learn how and why everything is done.  He would learn something
> > > as he goes along.  This will be much faster and more organised that
> > > the University of Google.
> > > 
> > > 4. I agree on the database, but I think this will evolve as we go
> > > along.  It is almost futile to try and determine what we will need at
> > > this stage.  But we have to try none the less.  Again, maybe the
> > > Lauchpad Blueprint facility will be a great place to manage this
> > > process... after all that's why Ubuntu set it up.
> > > 
> > > 5. I must admit, I agree on the C++.  I was kind of looking forward to
> > > learning a new language, but it would have delayed the process.  I'm
> > > very experience in C++, but I'm an Embedded systems/command line
> > > developer.  I've only done GUI's in windows, not in Linux.  So there
> > > will be something new to learn... yeah!!
> > > 
> > > 6. I was also thinking that the name of the installer should not be
> > > linked to Devbuntu as it has a much wider scope.  In fact there may
> > > actually be scope for two separate projects, 
> > > a. the installer, and 
> > > b. the package selection for Devbuntu that will use the installer.
> > > 
> > > What about something like Software Configuration Advanced Management
> > > -- "SCAM"  :-D 
> > > 
> > > Regards
> > > Charl
> > 
> > 
>