From benny at xfce.org Wed Aug 24 13:08:15 2005 From: benny at xfce.org (Benedikt Meurer) Date: Wed, 24 Aug 2005 13:08:15 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C3640.8010007@sten-net.de> References: <430C3640.8010007@sten-net.de> Message-ID: <430C551F.5070309@xfce.org> Jannis Pohlmann wrote: > Hi all. Jannis, > Website: > http://installit.xfce.org (I'm just filling the Wiki with content) I have a few comments on whats currently visible on the wiki: 0. Name ------- This is not really important, just a cosmetic question: How about using "i2t" for directory/file names? 1. Dependencies --------------- I think it's not a good idea to add python-glade2 and installwatch/zengarden to the dependencies. Both are unnecessary and make it harder to use the installer. You can design the GUI with Glade and then quite easily transform that into Python code (if all fails, I can do that for you). And concerning installwatch: This is not something that is usually installed on the average system. You can do installation tracking just like InstallIt does now, by first installing to a temporary location, checking the files installed, and afterwards installing to the final location. This works for all but the most broken packages (which should be fixed anyways). 2. Paths -------- Hardcoding /etc and /var for the local paths is not a good idea, as that way you loose one of the best features of InstallIt: Local installation without root priviliges (which - for example - Olivier and I used very often to update certain machines at work, where we don't have root access). My attempt was to let the user choose a prefix under which everything is installed (including the installer/uninstaller information itself). I think this should be the way for the new InstallIt too. On first run, ask the user to select a toplevel directory where all stuff gets installed (you'll need some magic here to set sysconfdir to "/etc" in case the user selects "/usr", and the like, but that's easy and you can check the existing code to avoid trapping into the same wholes as I did :-). The selected prefix is saved in a special file in the users home directory (e.g. $XDG_CONFIG_HOME/InstallIt/prefix). Then the initial setup on the prefix is performed (e.g. mkdir "$prefix/etc/installit", mkdir "$prefix/var/cache/installit", ...). For unpacking and building, you should allow the user to specify a custom directory, and before trying to unpack/build, calculate the approx. space required for the building and check if enough space is available on the selected directory (this was one of the most oftenly reported problems with the previous installer). One final note about the config file location: It may be a good idea to allow the user to add overrides to a file $XDG_CONFIG_HOME/InstallIt/config.xml, so he/she can easily saves it's customizations and maintain it when upgrading InstallIt. 3. Single Instance ------------------ Again, "/var/lock" should not be hardcoded. And one word of warning concerning file locking: Locking can lead to very tricky problems with NFS if not configured properly. We had a problem with libxfce4mcs and locking on NFS already, that was very nasty. In case of the installer precise locking is not required. I'd suggest to just use a file "$prefix/var/lock/installit.pid", where a running instance stores it PID to, and when starting a new instance, you simply read that file, and try to kill($PID, 0) it. If the answer is positive, refuse to start. If something goes wrong, the user can simply delete the lock file and everything will be ok. You save a lot of trouble this way. 4. Mirror List -------------- It would be nice to have a name/description to each mirror. In addition it might be a good idea to add the country in which the mirror is located, so users can choose a mirror close to them. greets, Benedikt -- Xfce -- small, stable, fast -- http://www.xfce.org/ (__) (oo) /------\/ / | || * /\---/\ ~~ ~~ ...."Have you mooed today?"... From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 13:47:41 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 13:47:41 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C551F.5070309@xfce.org> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> Message-ID: <430C5E5D.8080605@unix-ag.uni-siegen.de> Benedikt Meurer wrote: > My attempt was to let the user choose a prefix under which everything is > installed (including the installer/uninstaller information itself). I > think this should be the way for the new InstallIt too. On first run, > ask the user to select a toplevel directory where all stuff gets > installed (you'll need some magic here to set sysconfdir to "/etc" in > case the user selects "/usr", and the like, but that's easy and you can > check the existing code to avoid trapping into the same wholes as I did :-). The problem with this attempt was, that it doesn't integrate easily with every packaging system. So, on a second thought, I'd suggest to ask the user whether he wants to use a packaging system on first startup, e.g. (*) RPM ( ) DEB ( ) Solaris Package Management ( ) BSD Package Management ( ) Custom installation prefix: [____________] You can easily autodetect the available package management system and preselect it: 1. If pkgadd is available, select "Solaris Package Management" 2. If pkg_add is available, select "BSD Package Management" 3. If dpkg is available, select "DEB" 4. If rpm is available, select "RPM" 5. Select "Custom installation prefix" and default to "/usr/local" if writable, else fallback to "$HOME/local" There are some systems missing from the above list, which may be added later (e.g. Darwin Ports, Gentoo Package Management, Lunar Package Management or Win32/Cygwin). In general the package/installation backend should be kept modular and easy to extend/exchange, with a well defined API implemented by the various backends. So, if for example, the user selects "RPM", InstallIt will query the settings from the local RPM system (sysconfdir, prefix, etc.) and use that. If the user selects "DEB", InstallIt will use the hardcoded values from the Debian Policy (sysconfdir is "/etc", prefix is "/usr", etc.). For "Solaris Package Management", prefix will be "/usr/local" or "/opt/i2t", preferrably "/usr/local". For "BSD Package Managment" prefix will be set to whatever pkg basedir is selected (usually "/usr/local" for Free/OpenBSD/DragonFly, "/usr/pkg" for NetBSD) by parsing the make.conf/mk.conf. Of course, binary packages can only be installed if the appropriate package management system is selected: E.g. I can only install .rpm's if I selected "RPM" earlier, likewise I can only install .tgz's/.tbz's if I selected "BSD", and so on. Benedikt From info at sten-net.de Wed Aug 24 13:50:09 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 13:50:09 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C551F.5070309@xfce.org> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> Message-ID: <430C5EF1.1020206@sten-net.de> Hi. Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Hi all. > > > Jannis, > > >>Website: >>http://installit.xfce.org (I'm just filling the Wiki with content) > > > I have a few comments on whats currently visible on the wiki: > > > 0. Name > ------- > This is not really important, just a cosmetic question: How about using > "i2t" for directory/file names? > Yeah, that would at least make them shorter. And perhaps the executable could be called "i2t" as well, otherwise the user might be confused. > > 1. Dependencies > --------------- > I think it's not a good idea to add python-glade2 and > installwatch/zengarden to the dependencies. Both are unnecessary and > make it harder to use the installer. You can design the GUI with Glade > and then quite easily transform that into Python code (if all fails, I > can do that for you). And concerning installwatch: This is not something > that is usually installed on the average system. You can do installation > tracking just like InstallIt does now, by first installing to a > temporary location, checking the files installed, and afterwards > installing to the final location. This works for all but the most broken > packages (which should be fixed anyways). Concerning Glade: Ok, I'll have a look into the ways of transforming Glade into Python code. The major disadvantage I see here is that each class connected to a GUI will grow lots larger. But we'll see. Concerning zengarden/installwatch: I wrote a tiny package management tool some weeks ago and tried it the way you did. Well, it's ok but I'd prefer to use something like zengarden. I don't know the packages zengarden depends on but if it's just standard C library or something like this perhaps shipping a precompiled version of zengarden within the InstallIt distribution could work? > > > 2. Paths > -------- > Hardcoding /etc and /var for the local paths is not a good idea, as that > way you loose one of the best features of InstallIt: Local installation > without root priviliges (which - for example - Olivier and I used very > often to update certain machines at work, where we don't have root access). I already thought about defining those paths in the config file. We can do that, no problem. Concerning the config file: My draft suggests /etc/installit/config.xml but with making InstallIt available for the usual user we'd have to put it in every user's home directory (fitting with freedesktop standards, of course). > > My attempt was to let the user choose a prefix under which everything is > installed (including the installer/uninstaller information itself). I > think this should be the way for the new InstallIt too. On first run, > ask the user to select a toplevel directory where all stuff gets > installed (you'll need some magic here to set sysconfdir to "/etc" in > case the user selects "/usr", and the like, but that's easy and you can > check the existing code to avoid trapping into the same wholes as I did :-). Right, the prefix feature is important. I didn't mention it on the Wiki yet but It's already been intended. > > The selected prefix is saved in a special file in the users home > directory (e.g. $XDG_CONFIG_HOME/InstallIt/prefix). Then the initial > setup on the prefix is performed (e.g. mkdir "$prefix/etc/installit", > mkdir "$prefix/var/cache/installit", ...). > > For unpacking and building, you should allow the user to specify a > custom directory, and before trying to unpack/build, calculate the > approx. space required for the building and check if enough space is > available on the selected directory (this was one of the most oftenly > reported problems with the previous installer). If we make one directory customizable we can just go for them all. Hehe. Every local path except the config file location is going to be changeable by the user. Calculating the approx. space is a good point, indeed. > > One final note about the config file location: It may be a good idea to > allow the user to add overrides to a file > $XDG_CONFIG_HOME/InstallIt/config.xml, so he/she can easily saves it's > customizations and maintain it when upgrading InstallIt. In my opinion, $XDG_CONFIG_HOME/i2t/config.xml (or ...InstallIt...) already contains the user's customizations. But we can offer a backup feature for it (and run it automatically if InstallIt is upgraded). > > 3. Single Instance > ------------------ > Again, "/var/lock" should not be hardcoded. And one word of warning > concerning file locking: Locking can lead to very tricky problems with > NFS if not configured properly. We had a problem with libxfce4mcs and > locking on NFS already, that was very nasty. In case of the installer > precise locking is not required. I'd suggest to just use a file > "$prefix/var/lock/installit.pid", where a running instance stores it PID > to, and when starting a new instance, you simply read that file, and try > to kill($PID, 0) it. If the answer is positive, refuse to start. If > something goes wrong, the user can simply delete the lock file and > everything will be ok. You save a lot of trouble this way. http://installit.gezeiten.org:2500/installit/show/EineInstanz ("Unsichere Methode") - I already prepared a solution for that. We can use this if you prefer it. For me, both are fine as they just work. > > > 4. Mirror List > -------------- > It would be nice to have a name/description to each mirror. In addition > it might be a good idea to add the country in which the mirror is > located, so users can choose a mirror close to them. We thought about name and description, too. To be honest, we considered it a waste of time. The domain ending (.de, .co.uk etc.) already may give a hint whether a mirror is close to the user or not. Personally, I prefer the puristic solution: Just choose between URLs. But since we're attempting to satisfy even less advanced users we can add information, of course. > > > greets, > Benedikt > Regards, Jannis From info at sten-net.de Wed Aug 24 13:58:41 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 13:58:41 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C5E5D.8080605@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> Message-ID: <430C60F1.4040707@sten-net.de> Benedikt Meurer schrieb: > Benedikt Meurer wrote: > >>My attempt was to let the user choose a prefix under which everything is >>installed (including the installer/uninstaller information itself). I >>think this should be the way for the new InstallIt too. On first run, >>ask the user to select a toplevel directory where all stuff gets >>installed (you'll need some magic here to set sysconfdir to "/etc" in >>case the user selects "/usr", and the like, but that's easy and you can >>check the existing code to avoid trapping into the same wholes as I did :-). > > > The problem with this attempt was, that it doesn't integrate easily with > every packaging system. So, on a second thought, I'd suggest to ask the > user whether he wants to use a packaging system on first startup, e.g. > > (*) RPM > ( ) DEB > ( ) Solaris Package Management > ( ) BSD Package Management > ( ) Custom installation prefix: [____________] > > You can easily autodetect the available package management system and > preselect it: > > 1. If pkgadd is available, select "Solaris Package Management" > 2. If pkg_add is available, select "BSD Package Management" > 3. If dpkg is available, select "DEB" > 4. If rpm is available, select "RPM" > 5. Select "Custom installation prefix" and default to "/usr/local" if > writable, else fallback to "$HOME/local" > > There are some systems missing from the above list, which may be added > later (e.g. Darwin Ports, Gentoo Package Management, Lunar Package > Management or Win32/Cygwin). In general the package/installation backend > should be kept modular and easy to extend/exchange, with a well defined > API implemented by the various backends. > > So, if for example, the user selects "RPM", InstallIt will query the > settings from the local RPM system (sysconfdir, prefix, etc.) and use > that. If the user selects "DEB", InstallIt will use the hardcoded values > from the Debian Policy (sysconfdir is "/etc", prefix is "/usr", etc.). > For "Solaris Package Management", prefix will be "/usr/local" or > "/opt/i2t", preferrably "/usr/local". For "BSD Package Managment" prefix > will be set to whatever pkg basedir is selected (usually "/usr/local" > for Free/OpenBSD/DragonFly, "/usr/pkg" for NetBSD) by parsing the > make.conf/mk.conf. > > Of course, binary packages can only be installed if the appropriate > package management system is selected: E.g. I can only install .rpm's if > I selected "RPM" earlier, likewise I can only install .tgz's/.tbz's if I > selected "BSD", and so on. Thanks, those information are a great help. Do you think of building binary packages out of all source packages when the user selects RPM or something like that on startup? So no source installation into the system, just building packages suitable for the platform and install them? Your words make me guess so, but that will be difficult since we'd have to look into all package management formats, then. I'd prefer installing source as source and binaries as binaries. Sources would have to be tracked on a test installation in order to uninstall them later. Binaries could be just removed by using the platform's package manager once again. Regards, Jannis From sofar at lunar-linux.org Wed Aug 24 13:58:57 2005 From: sofar at lunar-linux.org (Auke Kok) Date: Wed, 24 Aug 2005 13:58:57 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C5EF1.1020206@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> Message-ID: <430C6101.9090209@lunar-linux.org> Jannis Pohlmann wrote: > >Concerning zengarden/installwatch: I wrote a tiny package management >tool some weeks ago and tried it the way you did. Well, it's ok but I'd >prefer to use something like zengarden. I don't know the packages >zengarden depends on but if it's just standard C library or something >like this perhaps shipping a precompiled version of zengarden within the >InstallIt distribution could work? > Not entirely sure but both zengarden and installwatch are linux-only I think, which might limit you a bit too much. sofar From info at sten-net.de Wed Aug 24 14:02:20 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 14:02:20 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C6101.9090209@lunar-linux.org> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C6101.9090209@lunar-linux.org> Message-ID: <430C61CC.8030404@sten-net.de> Auke Kok schrieb: > Jannis Pohlmann wrote: > > >>Concerning zengarden/installwatch: I wrote a tiny package management >>tool some weeks ago and tried it the way you did. Well, it's ok but I'd >>prefer to use something like zengarden. I don't know the packages >>zengarden depends on but if it's just standard C library or something >>like this perhaps shipping a precompiled version of zengarden within the >>InstallIt distribution could work? >> > > > Not entirely sure but both zengarden and installwatch are linux-only I > think, which might limit you a bit too much. > > sofar Good to know. That's a limitation we can't ignore in this case. Thanks for the hint. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 14:12:59 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 14:12:59 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C5EF1.1020206@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> Message-ID: <430C644B.8090700@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Concerning Glade: Ok, I'll have a look into the ways of transforming > Glade into Python code. The major disadvantage I see here is that each > class connected to a GUI will grow lots larger. But we'll see. You can keep that in a single method init_gui() for each class, that'll help to keep it in one place. It's better to have more code in this case, so we can hopefully reach the "out-of-the-box"-goal one day. > Concerning zengarden/installwatch: I wrote a tiny package management > tool some weeks ago and tried it the way you did. Well, it's ok but I'd > prefer to use something like zengarden. I don't know the packages > zengarden depends on but if it's just standard C library or something > like this perhaps shipping a precompiled version of zengarden within the > InstallIt distribution could work? A precompiled version for N different systems? That is unlikely to work. You could probably compile it on demand (if it is portable), but then you depend on atleast the compiler and the dev packages for the system stuff, which goes against the "out-of-the-box" attempt with binary package installation. >>3. Single Instance >>------------------ >>Again, "/var/lock" should not be hardcoded. And one word of warning >>concerning file locking: Locking can lead to very tricky problems with >>NFS if not configured properly. We had a problem with libxfce4mcs and >>locking on NFS already, that was very nasty. In case of the installer >>precise locking is not required. I'd suggest to just use a file >>"$prefix/var/lock/installit.pid", where a running instance stores it PID >>to, and when starting a new instance, you simply read that file, and try >>to kill($PID, 0) it. If the answer is positive, refuse to start. If >>something goes wrong, the user can simply delete the lock file and >>everything will be ok. You save a lot of trouble this way. > > http://installit.gezeiten.org:2500/installit/show/EineInstanz > ("Unsichere Methode") - I already prepared a solution for that. We can > use this if you prefer it. For me, both are fine as they just work. Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's really not worth the trouble with fcntl()/lockf() locking. And we're not developing a critical database, so if a user manages to start two instances of InstallIt, then he'll run into trouble and may remember to read the documentation when he uses a software next time. ;-) >>4. Mirror List >>-------------- >>It would be nice to have a name/description to each mirror. In addition >>it might be a good idea to add the country in which the mirror is >>located, so users can choose a mirror close to them. > > We thought about name and description, too. To be honest, we considered > it a waste of time. The domain ending (.de, .co.uk etc.) already may > give a hint whether a mirror is close to the user or not. > Personally, I prefer the puristic solution: Just choose between URLs. > But since we're attempting to satisfy even less advanced users we can > add information, of course. Unfortunately domain endings are pretty useless these days. I'd prefer to have atleast a name/description and the country attached to the mirrors. And the GUI should sort the mirrors by country, e.g.: * Germany - Bla - Blub * Netherlands - Narf - Foo ... Preselecting the last used mirror (or the closest mirror on first run, e.g. the first mirror for the country of the user). The less user interaction you need, the better (but still provide the possibility to change things if the user wants to). > Regards, > Jannis Benedikt From info at sten-net.de Wed Aug 24 14:21:18 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 14:21:18 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C644B.8090700@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> Message-ID: <430C663E.7070209@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Concerning Glade: Ok, I'll have a look into the ways of transforming >>Glade into Python code. The major disadvantage I see here is that each >>class connected to a GUI will grow lots larger. But we'll see. > > > You can keep that in a single method init_gui() for each class, that'll > help to keep it in one place. It's better to have more code in this > case, so we can hopefully reach the "out-of-the-box"-goal one day. That's fine. Any tutorials/documentation on this in the web that you know of? > > >>Concerning zengarden/installwatch: I wrote a tiny package management >>tool some weeks ago and tried it the way you did. Well, it's ok but I'd >>prefer to use something like zengarden. I don't know the packages >>zengarden depends on but if it's just standard C library or something >>like this perhaps shipping a precompiled version of zengarden within the >>InstallIt distribution could work? > > > A precompiled version for N different systems? That is unlikely to work. > You could probably compile it on demand (if it is portable), but then > you depend on atleast the compiler and the dev packages for the system > stuff, which goes against the "out-of-the-box" attempt with binary > package installation. Okay, zengarden/installwatch is dropped. > >>>3. Single Instance >>>------------------ >>>Again, "/var/lock" should not be hardcoded. And one word of warning >>>concerning file locking: Locking can lead to very tricky problems with >>>NFS if not configured properly. We had a problem with libxfce4mcs and >>>locking on NFS already, that was very nasty. In case of the installer >>>precise locking is not required. I'd suggest to just use a file >>>"$prefix/var/lock/installit.pid", where a running instance stores it PID >>>to, and when starting a new instance, you simply read that file, and try >>>to kill($PID, 0) it. If the answer is positive, refuse to start. If >>>something goes wrong, the user can simply delete the lock file and >>>everything will be ok. You save a lot of trouble this way. >> >>http://installit.gezeiten.org:2500/installit/show/EineInstanz >>("Unsichere Methode") - I already prepared a solution for that. We can >>use this if you prefer it. For me, both are fine as they just work. > > > Use kill($PID, 0) rather than /proc/$PID and you're ok. Trust me, it's > really not worth the trouble with fcntl()/lockf() locking. And we're not > developing a critical database, so if a user manages to start two > instances of InstallIt, then he'll run into trouble and may remember to > read the documentation when he uses a software next time. ;-) Okay, I'll try using kill($PID, 0). I already thought about the fact that /proc might depend on the distribution of the user so this sounds like a smarter solution. > > >>>4. Mirror List >>>-------------- >>>It would be nice to have a name/description to each mirror. In addition >>>it might be a good idea to add the country in which the mirror is >>>located, so users can choose a mirror close to them. >> >>We thought about name and description, too. To be honest, we considered >>it a waste of time. The domain ending (.de, .co.uk etc.) already may >>give a hint whether a mirror is close to the user or not. >>Personally, I prefer the puristic solution: Just choose between URLs. >>But since we're attempting to satisfy even less advanced users we can >>add information, of course. > > > Unfortunately domain endings are pretty useless these days. I'd prefer > to have atleast a name/description and the country attached to the > mirrors. And the GUI should sort the mirrors by country, e.g.: > > * Germany > - Bla > - Blub > * Netherlands > - Narf > - Foo > ... Yeah. I just updated the Wiki: http://installit.xfce.org/trac.cgi/wiki/MirrorList > > Preselecting the last used mirror (or the closest mirror on first run, > e.g. the first mirror for the country of the user). The less user > interaction you need, the better (but still provide the possibility to > change things if the user wants to). Good idea, I'm going to keep that in mind. > Benedikt - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 14:29:42 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 14:29:42 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C60F1.4040707@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> Message-ID: <430C6836.9010805@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>The problem with this attempt was, that it doesn't integrate easily with >>every packaging system. So, on a second thought, I'd suggest to ask the >>user whether he wants to use a packaging system on first startup, e.g. >> >> (*) RPM >> ( ) DEB >> ( ) Solaris Package Management >> ( ) BSD Package Management >> ( ) Custom installation prefix: [____________] >> >>You can easily autodetect the available package management system and >>preselect it: >> >> 1. If pkgadd is available, select "Solaris Package Management" >> 2. If pkg_add is available, select "BSD Package Management" >> 3. If dpkg is available, select "DEB" >> 4. If rpm is available, select "RPM" >> 5. Select "Custom installation prefix" and default to "/usr/local" if >>writable, else fallback to "$HOME/local" >> >>There are some systems missing from the above list, which may be added >>later (e.g. Darwin Ports, Gentoo Package Management, Lunar Package >>Management or Win32/Cygwin). In general the package/installation backend >>should be kept modular and easy to extend/exchange, with a well defined >>API implemented by the various backends. >> >>So, if for example, the user selects "RPM", InstallIt will query the >>settings from the local RPM system (sysconfdir, prefix, etc.) and use >>that. If the user selects "DEB", InstallIt will use the hardcoded values >>from the Debian Policy (sysconfdir is "/etc", prefix is "/usr", etc.). >>For "Solaris Package Management", prefix will be "/usr/local" or >>"/opt/i2t", preferrably "/usr/local". For "BSD Package Managment" prefix >>will be set to whatever pkg basedir is selected (usually "/usr/local" >>for Free/OpenBSD/DragonFly, "/usr/pkg" for NetBSD) by parsing the >>make.conf/mk.conf. >> >>Of course, binary packages can only be installed if the appropriate >>package management system is selected: E.g. I can only install .rpm's if >>I selected "RPM" earlier, likewise I can only install .tgz's/.tbz's if I >>selected "BSD", and so on. > > > Thanks, those information are a great help. > > Do you think of building binary packages out of all source packages when > the user selects RPM or something like that on startup? So no source > installation into the system, just building packages suitable for the > platform and install them? Your words make me guess so, but that will be > difficult since we'd have to look into all package management formats, then. Exactly. So to the user it should not matter whether a binary package is available or not (well, except that building source requires -devel packages, but that's another story). If you install from source, after the "make install" step is done, the package backend will be asked to register the installed package with the package management system. Then, if the user selects uninstall, InstallIt will ask the package backend to uninstall the package from the system (e.g. using pkg_deinstall, pkg_delete, dpkg -P, rpm -e, ...). It looks like a lot of work, but it's really trivial for most of the systems (e.g. on Debian systems, you basicly add your files for /var/lib/dpkg/info/ and a note to /var/lib/dpkg/status and you are done, etc.). I can write the backends for the 4 systems mentioned above. The important thing - as mentioned already - is to define a good API for the package backends, which covers everything we need to be platform independent. There are several things that will need to be done for binary and source packages, and for source-only installation, which will need to be addressed: 1) When installing new MIME types, you'll need to call update-mime-database on the mime directory after installation and after removal of the package. There are several ways to address this problem, and each has disadvantages. 2) Same for the .desktop files, where you'll need to call update-desktop-database. 3) For icons, you'll need to call gtk-update-icon-cache on the themes to which new icons where installed to (hicolor in most cases), and same on removal. These and other points make me think, that it might be a good idea to turn the source-only variant into a "pseudo package management system", which will also implement the above API. So, from the upper layers (i.e. the GUI), you use solely the backend API to "communicate with the underlying system". > Regards, > Jannis Benedikt From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 14:32:51 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 14:32:51 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C663E.7070209@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <430C663E.7070209@sten-net.de> Message-ID: <430C68F3.3080105@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>>Concerning Glade: Ok, I'll have a look into the ways of transforming >>>Glade into Python code. The major disadvantage I see here is that each >>>class connected to a GUI will grow lots larger. But we'll see. >> >>You can keep that in a single method init_gui() for each class, that'll >>help to keep it in one place. It's better to have more code in this >>case, so we can hopefully reach the "out-of-the-box"-goal one day. > > That's fine. Any tutorials/documentation on this in the web that you > know of? The "PyGTK 2.0 Tutorial" should do. >>Unfortunately domain endings are pretty useless these days. I'd prefer >>to have atleast a name/description and the country attached to the >>mirrors. And the GUI should sort the mirrors by country, e.g.: >> >>* Germany >> - Bla >> - Blub >>* Netherlands >> - Narf >> - Foo >>... > > Yeah. I just updated the Wiki: > http://installit.xfce.org/trac.cgi/wiki/MirrorList Great. ;-) > - Jannis Benedikt From info at sten-net.de Wed Aug 24 14:36:33 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 14:36:33 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C6836.9010805@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> Message-ID: <430C69D1.9090304@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>>The problem with this attempt was, that it doesn't integrate easily with >>>every packaging system. So, on a second thought, I'd suggest to ask the >>>user whether he wants to use a packaging system on first startup, e.g. >>> >>> (*) RPM >>> ( ) DEB >>> ( ) Solaris Package Management >>> ( ) BSD Package Management >>> ( ) Custom installation prefix: [____________] >>> >>>You can easily autodetect the available package management system and >>>preselect it: >>> >>> 1. If pkgadd is available, select "Solaris Package Management" >>> 2. If pkg_add is available, select "BSD Package Management" >>> 3. If dpkg is available, select "DEB" >>> 4. If rpm is available, select "RPM" >>> 5. Select "Custom installation prefix" and default to "/usr/local" if >>>writable, else fallback to "$HOME/local" >>> >>>There are some systems missing from the above list, which may be added >>>later (e.g. Darwin Ports, Gentoo Package Management, Lunar Package >>>Management or Win32/Cygwin). In general the package/installation backend >>>should be kept modular and easy to extend/exchange, with a well defined >>>API implemented by the various backends. >>> >>>So, if for example, the user selects "RPM", InstallIt will query the >>>settings from the local RPM system (sysconfdir, prefix, etc.) and use >>>that. If the user selects "DEB", InstallIt will use the hardcoded values >> >>>from the Debian Policy (sysconfdir is "/etc", prefix is "/usr", etc.). >> >>>For "Solaris Package Management", prefix will be "/usr/local" or >>>"/opt/i2t", preferrably "/usr/local". For "BSD Package Managment" prefix >>>will be set to whatever pkg basedir is selected (usually "/usr/local" >>>for Free/OpenBSD/DragonFly, "/usr/pkg" for NetBSD) by parsing the >>>make.conf/mk.conf. >>> >>>Of course, binary packages can only be installed if the appropriate >>>package management system is selected: E.g. I can only install .rpm's if >>>I selected "RPM" earlier, likewise I can only install .tgz's/.tbz's if I >>>selected "BSD", and so on. >> >> >>Thanks, those information are a great help. >> >>Do you think of building binary packages out of all source packages when >>the user selects RPM or something like that on startup? So no source >>installation into the system, just building packages suitable for the >>platform and install them? Your words make me guess so, but that will be >>difficult since we'd have to look into all package management formats, then. > > > Exactly. So to the user it should not matter whether a binary package is > available or not (well, except that building source requires -devel > packages, but that's another story). > > If you install from source, after the "make install" step is done, the > package backend will be asked to register the installed package with the > package management system. > > Then, if the user selects uninstall, InstallIt will ask the package > backend to uninstall the package from the system (e.g. using > pkg_deinstall, pkg_delete, dpkg -P, rpm -e, ...). > > It looks like a lot of work, but it's really trivial for most of the > systems (e.g. on Debian systems, you basicly add your files for > /var/lib/dpkg/info/ and a note to /var/lib/dpkg/status and you are done, > etc.). I can write the backends for the 4 systems mentioned above. The > important thing - as mentioned already - is to define a good API for the > package backends, which covers everything we need to be platform > independent. Okay, would be great if you could develop this API (if you have the time to do it) and some of the backends. You seem to have higher knowledge regarding this topic than I or Johannes. > > There are several things that will need to be done for binary and source > packages, and for source-only installation, which will need to be addressed: > > 1) When installing new MIME types, you'll need to call > update-mime-database on the mime directory after installation and after > removal of the package. There are several ways to address this problem, > and each has disadvantages. > > 2) Same for the .desktop files, where you'll need to call > update-desktop-database. > > 3) For icons, you'll need to call gtk-update-icon-cache on the themes to > which new icons where installed to (hicolor in most cases), and same on > removal. > > These and other points make me think, that it might be a good idea to > turn the source-only variant into a "pseudo package management system", > which will also implement the above API. So, from the upper layers (i.e. > the GUI), you use solely the backend API to "communicate with the > underlying system". Sounds like a good way for me. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 14:40:51 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 14:40:51 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C69D1.9090304@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C69D1.9090304@sten-net.de> Message-ID: <430C6AD3.1010200@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>Exactly. So to the user it should not matter whether a binary package is >>available or not (well, except that building source requires -devel >>packages, but that's another story). >> >>If you install from source, after the "make install" step is done, the >>package backend will be asked to register the installed package with the >>package management system. >> >>Then, if the user selects uninstall, InstallIt will ask the package >>backend to uninstall the package from the system (e.g. using >>pkg_deinstall, pkg_delete, dpkg -P, rpm -e, ...). >> >>It looks like a lot of work, but it's really trivial for most of the >>systems (e.g. on Debian systems, you basicly add your files for >>/var/lib/dpkg/info/ and a note to /var/lib/dpkg/status and you are done, >>etc.). I can write the backends for the 4 systems mentioned above. The >>important thing - as mentioned already - is to define a good API for the >>package backends, which covers everything we need to be platform >>independent. > > Okay, would be great if you could develop this API (if you have the time > to do it) and some of the backends. You seem to have higher knowledge > regarding this topic than I or Johannes. Sure. I'll hopefully have more spare time next month. >>There are several things that will need to be done for binary and source >>packages, and for source-only installation, which will need to be addressed: >> >>1) When installing new MIME types, you'll need to call >>update-mime-database on the mime directory after installation and after >>removal of the package. There are several ways to address this problem, >>and each has disadvantages. >> >>2) Same for the .desktop files, where you'll need to call >>update-desktop-database. >> >>3) For icons, you'll need to call gtk-update-icon-cache on the themes to >>which new icons where installed to (hicolor in most cases), and same on >>removal. >> >>These and other points make me think, that it might be a good idea to >>turn the source-only variant into a "pseudo package management system", >>which will also implement the above API. So, from the upper layers (i.e. >>the GUI), you use solely the backend API to "communicate with the >>underlying system". > > Sounds like a good way for me. It'd be good if you could sum up the important points from this thread on the Wiki, as mailinglist threads tend to grow too fast to keep track of everything. ;-) > - Jannis Benedikt From info at sten-net.de Wed Aug 24 14:46:08 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 14:46:08 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C6AD3.1010200@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C69D1.9090304@sten-net.de> <430C6AD3.1010200@unix-ag.uni-siegen.de> Message-ID: <430C6C10.5080606@sten-net.de> > It'd be good if you could sum up the important points from this thread > on the Wiki, as mailinglist threads tend to grow too fast to keep track > of everything. ;-) > Sure, I'll do that. Regards, Jannis From tukem at iki.fi Wed Aug 24 15:06:44 2005 From: tukem at iki.fi (=?ISO-8859-1?Q?Tuukka_M=E4kinen?=) Date: Wed, 24 Aug 2005 16:06:44 +0300 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C551F.5070309@xfce.org> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> Message-ID: <430C70E4.5070800@iki.fi> Benedict listed lot of good stuff I wanted to say but I'll post my view of how system might work anyway. Perhaps it'll give some ideas to somebody. 1. Check what package manager plugins are installed 2. Show package manager selection dialog 3. Tell plugin to check if it exists on the system 3a. continue 3b. Error dialog 4. Show main view 4a. Get list of available packages from somewhere or use previously fetched list 4b. Update the list at some point. Automatically or on request? Install: 1. Show mirror list dialog with last used mirror preselected 2. Download sources for selected package 3. Ask installation paths from plugin 4. Configure && make & install to temporary location 5. Ask plugin to make package from the files in chroot 6. Ask plugin to install the created package using platform's package management system. Uninstall: 1. Here you could basicly show all packages from local system 2. Ask plugin to remove selected package from the system using platform's package management system. For API: ---------- *is_installed Check whether the package manager for that plugin is installed *get_*path Bunch of functions for getting default path for different installation directories *get_list_of_packages Should be obvious *get_package_info(package name) Get information on package from local system. Package name should correspond to one gotten from get_list_of_packages *create_package(path to chroot) Create e.g rpm from files installed to temporary location *install_package(path to package) Install package to system using local package manager *uninstall_package(package name) Tuukka From info at sten-net.de Wed Aug 24 15:25:32 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 15:25:32 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C70E4.5070800@iki.fi> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> Message-ID: <430C754C.4090002@sten-net.de> Tuukka M?kinen schrieb: > Benedict listed lot of good stuff I wanted to say but I'll post my view of how > system might work anyway. Perhaps it'll give some ideas to somebody. > > > 1. Check what package manager plugins are installed > 2. Show package manager selection dialog > 3. Tell plugin to check if it exists on the system > 3a. continue > 3b. Error dialog > 4. Show main view > 4a. Get list of available packages from somewhere or use previously fetched list > 4b. Update the list at some point. Automatically or on request? > In regard to those steps, I'd like to show you our first draft for the main window: http://installit.xfce.org/trac.cgi/wiki/UserInterface It features - a menu with access to preferences and server setup - manual update functionality - a large listview for displaying packages and package groups - a table containing information and an icon dependent on the package type - "install" and "uninstall" buttons We shouldn't bug the user with more than that. The download and installation wizard will be shown once you click install/remove and the main window will be hidden, then. > > Install: > 1. Show mirror list dialog with last used mirror preselected > 2. Download sources for selected package > 3. Ask installation paths from plugin > 4. Configure && make & install to temporary location > 5. Ask plugin to make package from the files in chroot > 6. Ask plugin to install the created package using platform's package management > system. I disagree with 1.) here. Once you've set up a mirror and fetched the packages list from there you can't change it after selecting packages for installation. So on the first run of InstallIt we'll let the user decide which mirror he wants to use. He can change this later but that will make the whole package list obsolete. I have to think about that once again. Perhaps we should store packages and stuff locally in a directory named after the mirror in order to separate them from each other mirror's packages. Anyway, I don't like to mix the mirrors. - Jannis From masse_nicolas at yahoo.fr Wed Aug 24 15:49:59 2005 From: masse_nicolas at yahoo.fr (Nicolas Masse) Date: Wed, 24 Aug 2005 15:49:59 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C70E4.5070800@iki.fi> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> Message-ID: <20050824154959.476f6290.masse_nicolas@yahoo.fr> Here is my point of view af all that: On Wed, 24 Aug 2005 16:06:44 +0300 Tuukka M?kinen wrote: > > Benedict listed lot of good stuff I wanted to say but I'll post my view of how > system might work anyway. Perhaps it'll give some ideas to somebody. > > > 1. Check what package manager plugins are installed > 2. Show package manager selection dialog 1st run only. Then can be available throught a separate dialog. > 3. Tell plugin to check if it exists on the system > 3a. continue > 3b. Error dialog yes, we must not forget that :-). But, perhaps would it be better to just show available package manager systems in 2. (note verification can also be done to verify that the pre-selected system is always available, even if the opposite is unlikely to happen) > 4. Show main view > 4a. Get list of available packages from somewhere or use previously fetched list > 4b. Update the list at some point. Automatically or on request? > Since we want something out of the box, I think default must be automatic (or at least ask the user to update every week for example). Also we can do here a distinction between tha packages installed on the local computer (to see if they were updated for example) and the others. > > Install: > 1. Show mirror list dialog with last used mirror preselected Hmm, IMHO not by default. Perhaps for the 1st run. Then available throught a separate dialog. > 2. Download sources for selected package > 3. Ask installation paths from plugin yes, with a default one pre-selected. > 4. Configure && make & install to temporary location > 5. Ask plugin to make package from the files in chroot > 6. Ask plugin to install the created package using platform's package management > system. > Uninstall: > 1. Here you could basicly show all packages from local system > 2. Ask plugin to remove selected package from the system using platform's > package management system. > > ok for me. > For API: > ---------- > > *is_installed > Check whether the package manager for that plugin is installed > > *get_*path > Bunch of functions for getting default path for different installation directories > > *get_list_of_packages > Should be obvious > > *get_package_info(package name) > Get information on package from local system. Package name should correspond to > one gotten from get_list_of_packages > > *create_package(path to chroot) > Create e.g rpm from files installed to temporary location > > *install_package(path to package) > Install package to system using local package manager > > *uninstall_package(package name) > > > Tuukka Masse Nicolas > _______________________________________________ > Installit-dev mailing list > Installit-dev at xfce.org > http://foo-projects.org/mailman/listinfo/installit-dev From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 16:01:46 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 16:01:46 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C754C.4090002@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <430C754C.4090002@sten-net.de> Message-ID: <430C7DCA.2040002@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > In regard to those steps, I'd like to show you our first draft for the > main window: http://installit.xfce.org/trac.cgi/wiki/UserInterface > > It features > > - a menu with access to preferences and server setup > - manual update functionality > - a large listview for displaying packages and package groups > - a table containing information and an icon dependent on the package > type > - "install" and "uninstall" buttons > > We shouldn't bug the user with more than that. The download and > installation wizard will be shown once you click install/remove and the > main window will be hidden, then. Looks good, tho the Description should be a TextView, because it is usually more than one line. Maybe put only Name and Version into the panel and add a button "More Info", which pops up a dialog with detailed information (as the dependencies are also unlikely to fit into one line). > - Jannis Benedikt From info at sten-net.de Wed Aug 24 16:11:04 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 16:11:04 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C7DCA.2040002@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <430C754C.4090002@sten-net.de> <430C7DCA.2040002@unix-ag.uni-siegen.de> Message-ID: <430C7FF8.5000609@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>In regard to those steps, I'd like to show you our first draft for the >>main window: http://installit.xfce.org/trac.cgi/wiki/UserInterface >> >>It features >> >> - a menu with access to preferences and server setup >> - manual update functionality >> - a large listview for displaying packages and package groups >> - a table containing information and an icon dependent on the package >> type >> - "install" and "uninstall" buttons >> >>We shouldn't bug the user with more than that. The download and >>installation wizard will be shown once you click install/remove and the >>main window will be hidden, then. > > > Looks good, tho the Description should be a TextView, because it is > usually more than one line. Maybe put only Name and Version into the > panel and add a button "More Info", which pops up a dialog with detailed > information (as the dependencies are also unlikely to fit into one line). > Yep, I'm going to arrange something like this. I doubt the information will ever fill the screen (on the usual >= 800x600 setup) so perhaps we could even provide a textview for the dependencies. - Jannis From info at sten-net.de Wed Aug 24 16:39:18 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 16:39:18 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C6836.9010805@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> Message-ID: <430C8696.7010905@sten-net.de> > Exactly. So to the user it should not matter whether a binary package is > available or not (well, except that building source requires -devel > packages, but that's another story). I've got another idea on this: We could highlight binary packages which fit the package manager backend selected by the user by changing their background color or something like that. This would mark them as "suitable" and might save some since the user's decision which packages to choose is easier, then. What do you think? - Jannis From info at sten-net.de Wed Aug 24 16:56:35 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 16:56:35 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <20050824154959.476f6290.masse_nicolas@yahoo.fr> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <20050824154959.476f6290.masse_nicolas@yahoo.fr> Message-ID: <430C8AA3.7060508@sten-net.de> Nicolas Masse schrieb: > Here is my point of view af all that: > > On Wed, 24 Aug 2005 16:06:44 +0300 > Tuukka M?kinen wrote: > > >>Benedict listed lot of good stuff I wanted to say but I'll post my view of how >>system might work anyway. Perhaps it'll give some ideas to somebody. >> >> >>1. Check what package manager plugins are installed >>2. Show package manager selection dialog > > > 1st run only. Then can be available throught a separate dialog. I think configuring some things on first startup is ok. But things must be kept simple, then so the average user isn't confronted with geeky stuff. > > >>3. Tell plugin to check if it exists on the system >>3a. continue >>3b. Error dialog > > > yes, we must not forget that :-). > But, perhaps would it be better to just show available package manager systems in 2. > (note verification can also be done to verify that the pre-selected system is always available, > even if the opposite is unlikely to happen) We don't need to check if the "plugin" (?) exists. We provide the user with a list of implementations/backends available and he chooses which one to use. That's all. > > >>4. Show main view >>4a. Get list of available packages from somewhere or use previously fetched list >>4b. Update the list at some point. Automatically or on request? >> > > Since we want something out of the box, I think default must be automatic (or at least ask the user to update every week for example). Also we can do here a distinction between tha packages installed on the local computer (to see if they were updated for example) and the others. At least on first startup you will neither have a mirror list nor a package list on your desktop. Due to this the program will automatically fetch one from the mirror you selected and, well, that's it. We then store the timestamp of that download and advise the user to update after a certain amount of time. Additionally, we should warn the user not to install when the list may be already outdated (= when it wasn't updated today). > >>Install: >>1. Show mirror list dialog with last used mirror preselected > > > Hmm, IMHO not by default. Perhaps for the 1st run. Then available throught a separate dialog. Right, for the first run. After this you'll have a separate server setup dialog reachable from the menu. > > >>2. Download sources for selected package >>3. Ask installation paths from plugin > > > yes, with a default one pre-selected. The backend API might need something like a flag which tells us there's no default installation path. For RPM, DEB etc. there is (/usr) but maybe on other systems there isn't (source for example). If there is *one* we can just head on. If not, we'll have to let the user decide (maybe only on the first run, too). - Jannis From info at sten-net.de Wed Aug 24 17:06:20 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:06:20 +0200 Subject: [Installit-dev] Mailinglist summaries Message-ID: <430C8CEC.3080104@sten-net.de> Hey all. I've set up a page for mailinglist summaries which I'll update from time to time when important things were stated: http://installit.xfce.org/trac.cgi/wiki/MailinglistSummaries - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 17:09:11 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 17:09:11 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C8696.7010905@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> Message-ID: <430C8D97.4020001@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>Exactly. So to the user it should not matter whether a binary package is >>available or not (well, except that building source requires -devel >>packages, but that's another story). > > > I've got another idea on this: We could highlight binary packages which > fit the package manager backend selected by the user by changing their > background color or something like that. This would mark them as > "suitable" and might save some since the user's decision which packages > to choose is easier, then. > > What do you think? Marking them is a good idea, but changing the background color is a bad idea, as it goes against the selected theme. Better add an icon to the row. > - Jannis Benedikt From info at sten-net.de Wed Aug 24 17:12:33 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:12:33 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C8D97.4020001@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> <430C8D97.4020001@unix-ag.uni-siegen.de> Message-ID: <430C8E61.5010608@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>>Exactly. So to the user it should not matter whether a binary package is >>>available or not (well, except that building source requires -devel >>>packages, but that's another story). >> >> >>I've got another idea on this: We could highlight binary packages which >>fit the package manager backend selected by the user by changing their >>background color or something like that. This would mark them as >>"suitable" and might save some since the user's decision which packages >>to choose is easier, then. >> >>What do you think? > > > Marking them is a good idea, but changing the background color is a bad > idea, as it goes against the selected theme. Better add an icon to the row. > Ah, right. Well, I already planned using icons to make the difference between package types visual but once we've got icons for that we can add a check mark to them or something which cannot be overseen (and of course, this should be explained somewhere). From webmaster at nebulon.de Wed Aug 24 17:15:04 2005 From: webmaster at nebulon.de (Johannes Zellner) Date: Wed, 24 Aug 2005 17:15:04 +0200 Subject: [Installit-dev] Mirrors Message-ID: <430C8EF8.4070803@nebulon.de> Hi I'd like to discuss the Mirror-System a bit. The idea of the Installer, is that it's really easy to use. So I think the available packages, provided by the packageList shouldn't be too many. For Example the user uses InstallIt for xfce and xfce-goodies. This List is already long and will be longer in the future. So my idea of the Mirrorsystem was: MainMirror: - holds Mirrorlist (not country-specific Mirrors, but PackageList-specific Mirrors) 1Mirror: - holds PackageList for xfce-goodies 2Mirror: - holds PackageList for xfce To spread the server-load for downloading, there will be a country-specific mirror-list in every headerfile. (like in Lunar) I think this makes it easier for people which want use InstallIt for their Projectbundles, which is completely away from xfce. Well this is just an freaky idea ;-) I like the other way, too. greets Johannes From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 17:22:37 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 17:22:37 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C8E61.5010608@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> <430C8D97.4020001@unix-ag.uni-siegen.de> <430C8E61.5010608@sten-net.de> Message-ID: <430C90BD.4000209@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>Marking them is a good idea, but changing the background color is a bad >>idea, as it goes against the selected theme. Better add an icon to the row. > > Ah, right. Well, I already planned using icons to make the difference > between package types visual but once we've got icons for that we can > add a check mark to them or something which cannot be overseen (and of > course, this should be explained somewhere). Definitely, but don't override user choices by changing the background color of tree view rows. Personally, I'd even prefer to have only one row per package and if the user selects a row for which both source and binary packages are available, popup a dialog: "Do you want to use binary package instead of compiling?" [x] Remember my choice [Yes] [No] And add a know to the preferences dialog to change this setting afterwards. Benedikt From info at sten-net.de Wed Aug 24 17:22:57 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:22:57 +0200 Subject: [Installit-dev] Mirrors In-Reply-To: <430C8EF8.4070803@nebulon.de> References: <430C8EF8.4070803@nebulon.de> Message-ID: <430C90D1.5060309@sten-net.de> Johannes Zellner schrieb: > Hi > > I'd like to discuss the Mirror-System a bit. > > The idea of the Installer, is that it's really easy to use. > So I think the available packages, provided by the packageList shouldn't > be too many. > For Example the user uses InstallIt for xfce and xfce-goodies. This List > is already long and will be longer in the future. > So my idea of the Mirrorsystem was: > > MainMirror: > - holds Mirrorlist (not country-specific Mirrors, but > PackageList-specific Mirrors) > > 1Mirror: > - holds PackageList for xfce-goodies > 2Mirror: > - holds PackageList for xfce > > To spread the server-load for downloading, there will be a > country-specific mirror-list in every headerfile. (like in Lunar) > So you mean instead of defining a country field for each server in the mirror list we should add this information to the header file of each packages, like this, right? http://myserver.de/package.tar.bz2 http://mir.co.uk/somewhere/package.tar.bz2 This way we'd first try to download e.g. from the German location and go through the list step by step when it fails. I find this idea pretty interesting as it would make personalized mirrors possible, without actually storing the packages on them. Even if we won't use this solution (yet, we have to wait for the others to tell us their opinion) I quite like the concept of external (and more than one) locations for one package. Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 17:25:36 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 17:25:36 +0200 Subject: [Installit-dev] Mirrors In-Reply-To: <430C8EF8.4070803@nebulon.de> References: <430C8EF8.4070803@nebulon.de> Message-ID: <430C9170.6060105@unix-ag.uni-siegen.de> Johannes Zellner wrote: > Hi > > I'd like to discuss the Mirror-System a bit. > > The idea of the Installer, is that it's really easy to use. > So I think the available packages, provided by the packageList shouldn't > be too many. > For Example the user uses InstallIt for xfce and xfce-goodies. This List > is already long and will be longer in the future. > So my idea of the Mirrorsystem was: > > MainMirror: > - holds Mirrorlist (not country-specific Mirrors, but > PackageList-specific Mirrors) > > 1Mirror: > - holds PackageList for xfce-goodies > 2Mirror: > - holds PackageList for xfce Somehow this doesn't seem to be very user friendly. Having to look for the right mirror to install Software X first is not very convinient. It would be easier if the user could install every package out of the box. To organize the list, it should probably be folded by category or use a tree model filter to display only items that match a certain pattern. Your idea also violates the idea of mirrors, as the servers no longer mirror a master, but instead each servers provides it's own list of packages. > greets > Johannes Benedikt From info at sten-net.de Wed Aug 24 17:28:53 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:28:53 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C90BD.4000209@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> <430C8D97.4020001@unix-ag.uni-siegen.de> <430C8E61.5010608@sten-net.de> <430C90BD.4000209@unix-ag.uni-siegen.de> Message-ID: <430C9235.50203@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>>Marking them is a good idea, but changing the background color is a bad >>>idea, as it goes against the selected theme. Better add an icon to the row. >> >>Ah, right. Well, I already planned using icons to make the difference >>between package types visual but once we've got icons for that we can >>add a check mark to them or something which cannot be overseen (and of >>course, this should be explained somewhere). > > > Definitely, but don't override user choices by changing the background > color of tree view rows. Personally, I'd even prefer to have only one > row per package and if the user selects a row for which both source and > binary packages are available, popup a dialog: > > "Do you want to use binary package instead of compiling?" > [x] Remember my choice > [Yes] [No] > Personally, I don't this idea. Maybe you want to install one package from source and another directly using a binary. I think we should separate the different package formats/types from each other. So for example (the layout is ugly, I know ...): | | | +-------------+---------------------+ | source-icon | Terminal 0.3.5 | +-------------+---------------------+ | rpm-icon | Terminal 0.3.5 | +-------------+---------------------+ | | | - Jannis From info at sten-net.de Wed Aug 24 17:34:18 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:34:18 +0200 Subject: [Installit-dev] Mirrors In-Reply-To: <430C9170.6060105@unix-ag.uni-siegen.de> References: <430C8EF8.4070803@nebulon.de> <430C9170.6060105@unix-ag.uni-siegen.de> Message-ID: <430C937A.8090005@sten-net.de> Benedikt Meurer schrieb: > Johannes Zellner wrote: > >>Hi >> >>I'd like to discuss the Mirror-System a bit. >> >>The idea of the Installer, is that it's really easy to use. >>So I think the available packages, provided by the packageList shouldn't >>be too many. >>For Example the user uses InstallIt for xfce and xfce-goodies. This List >>is already long and will be longer in the future. >>So my idea of the Mirrorsystem was: >> >>MainMirror: >> - holds Mirrorlist (not country-specific Mirrors, but >>PackageList-specific Mirrors) >> >>1Mirror: >> - holds PackageList for xfce-goodies >>2Mirror: >> - holds PackageList for xfce > > > Somehow this doesn't seem to be very user friendly. Having to look for > the right mirror to install Software X first is not very convinient. It > would be easier if the user could install every package out of the box. > > To organize the list, it should probably be folded by category or use a > tree model filter to display only items that match a certain pattern. Personally, I'd like to keep things simple: Just packages and groups one after the other. No trees or something. That's too much. I don't think InstallIt is intended to suit laaaarge repositories. But for small ones with about 5-50 packages it should be just fine. Okay, we could separate package groups from packages, that's ok. But please, no categories and tree structures. > > Your idea also violates the idea of mirrors, as the servers no longer > mirror a master, but instead each servers provides it's own list of > packages. Yeah, that's true ... Hm, okay. Mirrors shall stay mirrors so we won't spread packages around and spread chaos, hehe. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 17:42:25 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 17:42:25 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C9235.50203@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> <430C8D97.4020001@unix-ag.uni-siegen.de> <430C8E61.5010608@sten-net.de> <430C90BD.4000209@unix-ag.uni-siegen.de> <430C9235.50203@sten-net.de> Message-ID: <430C9561.2000702@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>>>Marking them is a good idea, but changing the background color is a bad >>>>idea, as it goes against the selected theme. Better add an icon to the row. >>> >>>Ah, right. Well, I already planned using icons to make the difference >>>between package types visual but once we've got icons for that we can >>>add a check mark to them or something which cannot be overseen (and of >>>course, this should be explained somewhere). >> >> >>Definitely, but don't override user choices by changing the background >>color of tree view rows. Personally, I'd even prefer to have only one >>row per package and if the user selects a row for which both source and >>binary packages are available, popup a dialog: >> >> "Do you want to use binary package instead of compiling?" >> [x] Remember my choice >> [Yes] [No] >> > > > Personally, I don't this idea. Maybe you want to install one package > from source and another directly using a binary. I think we should > separate the different package formats/types from each other. So for > example (the layout is ugly, I know ...): > > | | | > +-------------+---------------------+ > | source-icon | Terminal 0.3.5 | > +-------------+---------------------+ > | rpm-icon | Terminal 0.3.5 | > +-------------+---------------------+ > | | | What I don't like here is that the user always has to check the icon. In 99.99% of all cases you don't care if InstallIt compiles from source or installs a binary package. You just want it to install the package. The fact that it supports both source and binary installation is more or less an implementation detail, which should not be exposed too much to the user interface. > - Jannis Benedikt From info at sten-net.de Wed Aug 24 17:47:46 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 17:47:46 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C9561.2000702@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5E5D.8080605@unix-ag.uni-siegen.de> <430C60F1.4040707@sten-net.de> <430C6836.9010805@unix-ag.uni-siegen.de> <430C8696.7010905@sten-net.de> <430C8D97.4020001@unix-ag.uni-siegen.de> <430C8E61.5010608@sten-net.de> <430C90BD.4000209@unix-ag.uni-siegen.de> <430C9235.50203@sten-net.de> <430C9561.2000702@unix-ag.uni-siegen.de> Message-ID: <430C96A2.7050307@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>>>>Marking them is a good idea, but changing the background color is a bad >>>>>idea, as it goes against the selected theme. Better add an icon to the row. >>>> >>>>Ah, right. Well, I already planned using icons to make the difference >>>>between package types visual but once we've got icons for that we can >>>>add a check mark to them or something which cannot be overseen (and of >>>>course, this should be explained somewhere). >>> >>> >>>Definitely, but don't override user choices by changing the background >>>color of tree view rows. Personally, I'd even prefer to have only one >>>row per package and if the user selects a row for which both source and >>>binary packages are available, popup a dialog: >>> >>> "Do you want to use binary package instead of compiling?" >>> [x] Remember my choice >>> [Yes] [No] >>> >> >> >>Personally, I don't this idea. Maybe you want to install one package >>from source and another directly using a binary. I think we should >>separate the different package formats/types from each other. So for >>example (the layout is ugly, I know ...): >> >> | | | >> +-------------+---------------------+ >> | source-icon | Terminal 0.3.5 | >> +-------------+---------------------+ >> | rpm-icon | Terminal 0.3.5 | >> +-------------+---------------------+ >> | | | > > > What I don't like here is that the user always has to check the icon. In > 99.99% of all cases you don't care if InstallIt compiles from source or > installs a binary package. You just want it to install the package. > > The fact that it supports both source and binary installation is more or > less an implementation detail, which should not be exposed too much to > the user interface. > Okay, perhaps we should add the strings "(Source)" and "(RPM)" at the end of the package name (version will be in the info table) to make it even easier to understand. Well, I thought about the way of choosing between source and binary for a while and you're right: We should ask it once and then only install source packages where no binaries are available. This way we still separate development snapshots (or whatever) from official releases without any effort. - Jannis From tukem at iki.fi Wed Aug 24 20:41:38 2005 From: tukem at iki.fi (=?ISO-8859-15?Q?Tuukka_M=E4kinen?=) Date: Wed, 24 Aug 2005 21:41:38 +0300 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C8AA3.7060508@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <20050824154959.476f6290.masse_nicolas@yahoo.fr> <430C8AA3.7060508@sten-net.de> Message-ID: <430CBF62.8080107@iki.fi> Jannis Pohlmann wrote: > Nicolas Masse schrieb: > >>On Wed, 24 Aug 2005 16:06:44 +0300 >>Tuukka M?kinen wrote: >>>3. Tell plugin to check if it exists on the system >>>3a. continue >>>3b. Error dialog >> >> >>yes, we must not forget that :-). >>But, perhaps would it be better to just show available package manager systems in 2. >>(note verification can also be done to verify that the pre-selected system is always available, >>even if the opposite is unlikely to happen) > > > We don't need to check if the "plugin" (?) exists. We provide the user > with a list of implementations/backends available and he chooses which > one to use. That's all. Doh.. of course we don't check whether the plugin exists but whether the local system has that package manager or not. I agree Nicholas' way of doing the checks first and then showing just available package masters would be more user friendly. Doing the checks only when necessary would be little faster but admittedly it shouldn't take so long to do them. >>>2. Download sources for selected package >>>3. Ask installation paths from plugin >> >> >>yes, with a default one pre-selected. > > > The backend API might need something like a flag which tells us there's > no default installation path. For RPM, DEB etc. there is (/usr) but > maybe on other systems there isn't (source for example). If there is > *one* we can just head on. If not, we'll have to let the user decide > (maybe only on the first run, too). The way I meant this was that there are get_bin_path, get_data_path,... functions in the plugin for getting the paths. Plugin either gets the path from system or has some hardcoded default. Then the gui would show that path with a possibility to change it. If we would like to tell there is no default then plugin could just return empty string. -Tuukka From info at sten-net.de Wed Aug 24 20:46:18 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 20:46:18 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430CBF62.8080107@iki.fi> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <20050824154959.476f6290.masse_nicolas@yahoo.fr> <430C8AA3.7060508@sten-net.de> <430CBF62.8080107@iki.fi> Message-ID: <430CC07A.204@sten-net.de> Tuukka M?kinen schrieb: > Jannis Pohlmann wrote: > >>Nicolas Masse schrieb: >> >> >>>On Wed, 24 Aug 2005 16:06:44 +0300 >>>Tuukka M?kinen wrote: > > >>>>3. Tell plugin to check if it exists on the system >>>>3a. continue >>>>3b. Error dialog >>> >>> >>>yes, we must not forget that :-). >>>But, perhaps would it be better to just show available package manager systems in 2. >>>(note verification can also be done to verify that the pre-selected system is always available, >>>even if the opposite is unlikely to happen) >> >> >>We don't need to check if the "plugin" (?) exists. We provide the user >>with a list of implementations/backends available and he chooses which >>one to use. That's all. > > > Doh.. of course we don't check whether the plugin exists but whether the > local system has that package manager or not. I agree Nicholas' way of > doing the checks first and then showing just available package masters > would be more user friendly. Doing the checks only when necessary would > be little faster but admittedly it shouldn't take so long to do them. Sure, we won't let him choose a backend which isn't supported by his platform. > > > >>>>2. Download sources for selected package >>>>3. Ask installation paths from plugin >>> >>> >>>yes, with a default one pre-selected. >> >> >>The backend API might need something like a flag which tells us there's >>no default installation path. For RPM, DEB etc. there is (/usr) but >>maybe on other systems there isn't (source for example). If there is >>*one* we can just head on. If not, we'll have to let the user decide >>(maybe only on the first run, too). > > > The way I meant this was that there are get_bin_path, get_data_path,... > functions in the plugin for getting the paths. Plugin either gets the > path from system or has some hardcoded default. Then the gui would show > that path with a possibility to change it. If we would like to tell > there is no default then plugin could just return empty string. Yeah, something like this. Both solutions are very similar. I let Benny decide which way to go since he seems to be the one with the best knowledge about different platforms. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Wed Aug 24 21:13:20 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Wed, 24 Aug 2005 21:13:20 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430CC07A.204@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C70E4.5070800@iki.fi> <20050824154959.476f6290.masse_nicolas@yahoo.fr> <430C8AA3.7060508@sten-net.de> <430CBF62.8080107@iki.fi> <430CC07A.204@sten-net.de> Message-ID: <430CC6D0.6040505@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>>The backend API might need something like a flag which tells us there's >>>no default installation path. For RPM, DEB etc. there is (/usr) but >>>maybe on other systems there isn't (source for example). If there is >>>*one* we can just head on. If not, we'll have to let the user decide >>>(maybe only on the first run, too). >> >>The way I meant this was that there are get_bin_path, get_data_path,... >>functions in the plugin for getting the paths. Plugin either gets the >>path from system or has some hardcoded default. Then the gui would show >>that path with a possibility to change it. If we would like to tell >>there is no default then plugin could just return empty string. > > Yeah, something like this. Both solutions are very similar. I let Benny > decide which way to go since he seems to be the one with the best > knowledge about different platforms. The backend API needs accessors for atleast sysconfdir, localstatedir and prefix. The "source-only" backend will just return the previously selected prefix (and $prefix/etc for sysconfdir, $prefix/var for localstatedir). What we need is a way to ask the backend whether the prefix is configurable (for atleast "source-only" and "solaris"), and also a way to query the backend for a sane default, e.g.: class Backend: def has_configurable_prefix(self): return False def has_selected_prefix(self): return False def get_selected_prefix(self): return "" def set_selected_prefix(self, prefix): pass def SolarisBackend(Backend): def has_configurable_prefix(self): return True def has_selected_prefix(self): return self.__prefix_set def get_selected_prefix(self): if self.__prefix_set: return self.__prefix else: return "/usr/local" def set_selected_prefix(self, prefix): self.__prefix = prefix self.__prefix_set = True def SourceBackend(Backend): def has_configurable_prefix(self): return True def has_selected_prefix(self): return self.__prefix_set def get_selected_prefix(self): if self.__prefix_set: return self.__prefix elif is_writable("/usr/local"): return "/usr/local" else: return "$HOME/local" def set_selected_prefix(self, prefix): self.__prefix = prefix self.__prefix_set = True And so on... of course the backends will need to save their prefix information. > - Jannis Benedikt From info at sten-net.de Wed Aug 24 23:20:51 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Wed, 24 Aug 2005 23:20:51 +0200 Subject: [Installit-dev] XML namespaces and declarations Message-ID: <430CE4B3.4050608@sten-net.de> Hi all. I just wrote down a list of XML namespaces and declaration rules in the Wiki: http://installit.xfce.org/trac.cgi/wiki/XMLNamespaces I'm not sure yet but I guess my parsers are ready for mixing those formats with other XML dialects by identifying namespace and ids, etc. If someone tries to mix them (well, they aren't really supposed to be) you can just type something like this: Just as an example. Any concerns on this topic? Regards, Jannis From info at sten-net.de Thu Aug 25 13:10:03 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 25 Aug 2005 13:10:03 +0200 Subject: [Installit-dev] Code dir structure proposal Message-ID: <430DA70B.5090404@sten-net.de> Hi. I prepared a suggestion for structuring the source code: http://installit.xfce.org/trac.cgi/wiki/Paths#SourceCode Please have a look at the page and let me know what you think of it. Although the backends still will take some time to be ready I'd like to commit stuff like Parsers and i18n support as soon as possible. My stuff is well-separated so each module will be able to stand for its own. Regards, Jannis From info at sten-net.de Thu Aug 25 13:14:19 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 25 Aug 2005 13:14:19 +0200 Subject: [Installit-dev] i18n string extraction Message-ID: <430DA80B.50400@sten-net.de> Morning. Benny, is there a common way you do extract the strings and stuff with in other parts of Xfce? Something more automated than xgettext + msgfmt? I saw you store all po files and create the binary versions during the build process. We don't have a build process but of course we could let the user run some config/"build" scripts before he can use InstallIt, right? Perhaps during the typical python setup.py install process. - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Thu Aug 25 19:54:06 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 25 Aug 2005 19:54:06 +0200 Subject: [Installit-dev] i18n string extraction In-Reply-To: <430DA80B.50400@sten-net.de> References: <430DA80B.50400@sten-net.de> Message-ID: <430E05BE.6080005@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Morning. Hey Jannis, > Benny, is there a common way you do extract the strings and stuff with > in other parts of Xfce? Something more automated than xgettext + msgfmt? > > I saw you store all po files and create the binary versions during the > build process. We don't have a build process but of course we could let > the user run some config/"build" scripts before he can use InstallIt, > right? Perhaps during the typical python setup.py install process. IIRC, gettext has good support for python, see http://docs.python.org/lib/module-gettext.html So, why not just use gettext? It's easy to use and pretty much standard (e.g. translators will already know how to translate .po files, etc.). My vision is that the new installer can still be a single file download. E.g. a shell script, which includes a small tarfile with the python scripts and the generated .mo files. No need to install anything (of course there should also be an installable version, but that's an option, not a requirement). Just double-click the downloaded script in your favourite file manager, and the script untars the python source and runs it, and cleans up after execution. That way upgrading is just downloading the new file and deleting the old one. The generated gettext .mo files and the python source (we could even ship python byte code here, since it's platform independent, IIRC) should be small, so the extraction overhead can be ignored. Does that conform with your current plans? > - Jannis Benedikt From benedikt.meurer at unix-ag.uni-siegen.de Thu Aug 25 19:56:43 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 25 Aug 2005 19:56:43 +0200 Subject: [Installit-dev] Code dir structure proposal In-Reply-To: <430DA70B.5090404@sten-net.de> References: <430DA70B.5090404@sten-net.de> Message-ID: <430E065B.5000900@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Hi. > > I prepared a suggestion for structuring the source code: > http://installit.xfce.org/trac.cgi/wiki/Paths#SourceCode > > Please have a look at the page and let me know what you think of it. > Although the backends still will take some time to be ready I'd like to > commit stuff like Parsers and i18n support as soon as possible. My stuff > is well-separated so each module will be able to stand for its own. Looks good to me, go ahead. ;-) > Regards, > Jannis Benedikt From info at sten-net.de Thu Aug 25 20:14:22 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 25 Aug 2005 20:14:22 +0200 Subject: [Installit-dev] i18n string extraction In-Reply-To: <430E05BE.6080005@unix-ag.uni-siegen.de> References: <430DA80B.50400@sten-net.de> <430E05BE.6080005@unix-ag.uni-siegen.de> Message-ID: <430E0A7E.90301@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Morning. > > > Hey Jannis, > > >>Benny, is there a common way you do extract the strings and stuff with >>in other parts of Xfce? Something more automated than xgettext + msgfmt? >> >>I saw you store all po files and create the binary versions during the >>build process. We don't have a build process but of course we could let >>the user run some config/"build" scripts before he can use InstallIt, >>right? Perhaps during the typical python setup.py install process. > > > IIRC, gettext has good support for python, see > > http://docs.python.org/lib/module-gettext.html > > So, why not just use gettext? It's easy to use and pretty much standard > (e.g. translators will already know how to translate .po files, etc.). Yep, gettext is fine, it's just a mess to generate the .po files each time (since it has to collect information from various files). I once wrote a graphical solution for this for my employee (in Ruby). Let me see if I can write a solution in bash which allows us to define all files relevant for xgettext in just one file and generate the different .po files using that. Ok? > > My vision is that the new installer can still be a single file download. > E.g. a shell script, which includes a small tarfile with the python > scripts and the generated .mo files. No need to install anything (of > course there should also be an installable version, but that's an > option, not a requirement). Just double-click the downloaded script in > your favourite file manager, and the script untars the python source and > runs it, and cleans up after execution. That way upgrading is just > downloading the new file and deleting the old one. The generated gettext > .mo files and the python source (we could even ship python byte code > here, since it's platform independent, IIRC) should be small, so the > extraction overhead can be ignored. Does that conform with your current > plans? > Sounds like a good idea. Anyway, I would still provide both: A single-file-program and a distribution which is installed into the user's system. We could write a little helper program to generate the one-click-thingy for us so it won't be much effort for every release. But I don't like to integrate this functionality into the core sourcecode, I guess that's understandable. Of course, this will require to ship binary formats (.mo instead of .po and .pyc instead of .py) wherever possibly - not much of a problem, I think. Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Thu Aug 25 20:35:18 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 25 Aug 2005 20:35:18 +0200 Subject: [Installit-dev] i18n string extraction In-Reply-To: <430E0A7E.90301@sten-net.de> References: <430DA80B.50400@sten-net.de> <430E05BE.6080005@unix-ag.uni-siegen.de> <430E0A7E.90301@sten-net.de> Message-ID: <430E0F66.9010104@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Yep, gettext is fine, it's just a mess to generate the .po files each > time (since it has to collect information from various files). I once > wrote a graphical solution for this for my employee (in Ruby). Let me > see if I can write a solution in bash which allows us to define all > files relevant for xgettext in just one file and generate the different > .po files using that. Ok? A simple Makefile should do the trick. Or even a simple python script (because we're using python anyway). A dependency on bash doesn't sound like a good idea to me. >>My vision is that the new installer can still be a single file download. >>E.g. a shell script, which includes a small tarfile with the python >>scripts and the generated .mo files. No need to install anything (of >>course there should also be an installable version, but that's an >>option, not a requirement). Just double-click the downloaded script in >>your favourite file manager, and the script untars the python source and >>runs it, and cleans up after execution. That way upgrading is just >>downloading the new file and deleting the old one. The generated gettext >>.mo files and the python source (we could even ship python byte code >>here, since it's platform independent, IIRC) should be small, so the >>extraction overhead can be ignored. Does that conform with your current >>plans? > > Sounds like a good idea. Anyway, I would still provide both: A > single-file-program and a distribution which is installed into the > user's system. We could write a little helper program to generate the > one-click-thingy for us so it won't be much effort for every release. > But I don't like to integrate this functionality into the core > sourcecode, I guess that's understandable. We can port it from the Ruby scripts. The core should be organized that it can be used easily in both cases. > Regards, > Jannis Benedikt From info at sten-net.de Thu Aug 25 20:42:35 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 25 Aug 2005 20:42:35 +0200 Subject: [Installit-dev] i18n string extraction In-Reply-To: <430E0F66.9010104@unix-ag.uni-siegen.de> References: <430DA80B.50400@sten-net.de> <430E05BE.6080005@unix-ag.uni-siegen.de> <430E0A7E.90301@sten-net.de> <430E0F66.9010104@unix-ag.uni-siegen.de> Message-ID: <430E111B.9030304@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Yep, gettext is fine, it's just a mess to generate the .po files each >>time (since it has to collect information from various files). I once >>wrote a graphical solution for this for my employee (in Ruby). Let me >>see if I can write a solution in bash which allows us to define all >>files relevant for xgettext in just one file and generate the different >>.po files using that. Ok? > > > A simple Makefile should do the trick. Or even a simple python script > (because we're using python anyway). A dependency on bash doesn't sound > like a good idea to me. Makefiles might be misleading here. We'll use a Python script, that's even easier. > > >>>My vision is that the new installer can still be a single file download. >>>E.g. a shell script, which includes a small tarfile with the python >>>scripts and the generated .mo files. No need to install anything (of >>>course there should also be an installable version, but that's an >>>option, not a requirement). Just double-click the downloaded script in >>>your favourite file manager, and the script untars the python source and >>>runs it, and cleans up after execution. That way upgrading is just >>>downloading the new file and deleting the old one. The generated gettext >>>.mo files and the python source (we could even ship python byte code >>>here, since it's platform independent, IIRC) should be small, so the >>>extraction overhead can be ignored. Does that conform with your current >>>plans? >> >>Sounds like a good idea. Anyway, I would still provide both: A >>single-file-program and a distribution which is installed into the >>user's system. We could write a little helper program to generate the >>one-click-thingy for us so it won't be much effort for every release. >>But I don't like to integrate this functionality into the core >>sourcecode, I guess that's understandable. > > > We can port it from the Ruby scripts. The core should be organized that > it can be used easily in both cases. Well, the only thing we'll have to do is packing the right files into an archive, put this into the final shell script and deliver it. That shouldn't be too hard. I'm going to write down a note in the mailinglist summaries for this so we can recall this idea later. The shell script of course should execute the same script as the normal distribution does but I don't see any difficulties here, do you? - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Thu Aug 25 21:02:49 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Thu, 25 Aug 2005 21:02:49 +0200 Subject: [Installit-dev] i18n string extraction In-Reply-To: <430E111B.9030304@sten-net.de> References: <430DA80B.50400@sten-net.de> <430E05BE.6080005@unix-ag.uni-siegen.de> <430E0A7E.90301@sten-net.de> <430E0F66.9010104@unix-ag.uni-siegen.de> <430E111B.9030304@sten-net.de> Message-ID: <430E15D9.50802@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: >>>>My vision is that the new installer can still be a single file download. >>>>E.g. a shell script, which includes a small tarfile with the python >>>>scripts and the generated .mo files. No need to install anything (of >>>>course there should also be an installable version, but that's an >>>>option, not a requirement). Just double-click the downloaded script in >>>>your favourite file manager, and the script untars the python source and >>>>runs it, and cleans up after execution. That way upgrading is just >>>>downloading the new file and deleting the old one. The generated gettext >>>>.mo files and the python source (we could even ship python byte code >>>>here, since it's platform independent, IIRC) should be small, so the >>>>extraction overhead can be ignored. Does that conform with your current >>>>plans? >>> >>>Sounds like a good idea. Anyway, I would still provide both: A >>>single-file-program and a distribution which is installed into the >>>user's system. We could write a little helper program to generate the >>>one-click-thingy for us so it won't be much effort for every release. >>>But I don't like to integrate this functionality into the core >>>sourcecode, I guess that's understandable. >> >>We can port it from the Ruby scripts. The core should be organized that >>it can be used easily in both cases. > > Well, the only thing we'll have to do is packing the right files into an > archive, put this into the final shell script and deliver it. That > shouldn't be too hard. I'm going to write down a note in the mailinglist > summaries for this so we can recall this idea later. > > The shell script of course should execute the same script as the normal > distribution does but I don't see any difficulties here, do you? Nope, it's really easy. We store the python stuff in a tar file, embed it into a portable shell script, then on execution, once extracted we just run the main class. > - Jannis Benedikt From info at sten-net.de Thu Aug 25 22:16:48 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Thu, 25 Aug 2005 22:16:48 +0200 Subject: [Installit-dev] Code dir structure proposal In-Reply-To: <430E065B.5000900@unix-ag.uni-siegen.de> References: <430DA70B.5090404@sten-net.de> <430E065B.5000900@unix-ag.uni-siegen.de> Message-ID: <430E2730.10006@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Hi. >> >>I prepared a suggestion for structuring the source code: >>http://installit.xfce.org/trac.cgi/wiki/Paths#SourceCode >> >>Please have a look at the page and let me know what you think of it. >>Although the backends still will take some time to be ready I'd like to >>commit stuff like Parsers and i18n support as soon as possible. My stuff >>is well-separated so each module will be able to stand for its own. > > > Looks good to me, go ahead. ;-) > I just imported that structure into SVN. I created a directory named "Helpers" where we can put the po-generating script and the single-file-installer generator into once they're ready. We still have to create I18n/locale/(de|en|..)/LC_MESSAGES/ but I suggest that we do this with another helper script which transforms the a .po file into a .mo file and puts it into the correct locale directory. So far, so good. Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Fri Aug 26 00:00:11 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Fri, 26 Aug 2005 00:00:11 +0200 Subject: [Installit-dev] [Xfce4-commits] r17073 - in installit/trunk/I18n: . locale locale/de locale/fr In-Reply-To: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> References: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> Message-ID: <430E3F6B.8050705@unix-ag.uni-siegen.de> Jannis, > Added: > installit/trunk/I18n/I18n.py > installit/trunk/I18n/__init__.py > installit/trunk/I18n/locale/ > installit/trunk/I18n/locale/de/ > installit/trunk/I18n/locale/de/LC_MESSAGES/ > installit/trunk/I18n/locale/fr/ > installit/trunk/I18n/locale/fr/LC_MESSAGES/ I don't think it's a good idea to add the locale/ tree to the SVN repository, since it contains only generated files. Just create the directory tree in the sandbox on-demand. Benedikt From info at sten-net.de Fri Aug 26 00:02:07 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Fri, 26 Aug 2005 00:02:07 +0200 Subject: [Installit-dev] [Xfce4-commits] r17073 - in installit/trunk/I18n: . locale locale/de locale/fr In-Reply-To: <430E3F6B.8050705@unix-ag.uni-siegen.de> References: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> <430E3F6B.8050705@unix-ag.uni-siegen.de> Message-ID: <430E3FDF.9070902@sten-net.de> Benedikt Meurer schrieb: > Jannis, > > >>Added: >> installit/trunk/I18n/I18n.py >> installit/trunk/I18n/__init__.py >> installit/trunk/I18n/locale/ >> installit/trunk/I18n/locale/de/ >> installit/trunk/I18n/locale/de/LC_MESSAGES/ >> installit/trunk/I18n/locale/fr/ >> installit/trunk/I18n/locale/fr/LC_MESSAGES/ > > > I don't think it's a good idea to add the locale/ tree to the SVN > repository, since it contains only generated files. Just create the > directory tree in the sandbox on-demand. Okay, you're the one having experiences with that a lot (in Xfce). I'll remove it again. - Jannis From info at sten-net.de Fri Aug 26 00:05:45 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Fri, 26 Aug 2005 00:05:45 +0200 Subject: [Installit-dev] [Xfce4-commits] r17073 - in installit/trunk/I18n: . locale locale/de locale/fr In-Reply-To: <430E3FDF.9070902@sten-net.de> References: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> <430E3F6B.8050705@unix-ag.uni-siegen.de> <430E3FDF.9070902@sten-net.de> Message-ID: <430E40B9.20307@sten-net.de> Benny, what do you think, would a file FILES in I18n/po/ would be ok for maintaining the source files relevant for the .po files or would it be better to scan for .py files in the helper script which generates the .mo files? - Jannis From benedikt.meurer at unix-ag.uni-siegen.de Fri Aug 26 00:11:10 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Fri, 26 Aug 2005 00:11:10 +0200 Subject: [Installit-dev] [Xfce4-commits] r17073 - in installit/trunk/I18n: . locale locale/de locale/fr In-Reply-To: <430E40B9.20307@sten-net.de> References: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> <430E3F6B.8050705@unix-ag.uni-siegen.de> <430E3FDF.9070902@sten-net.de> <430E40B9.20307@sten-net.de> Message-ID: <430E41FE.4040805@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Benny, > > what do you think, would a file FILES in I18n/po/ would be ok for > maintaining the source files relevant for the .po files or would it be > better to scan for .py files in the helper script which generates the > .mo files? The usual way is to put a po/POTFILES there which contains a list of relative paths to files which contain translatable strings. > - Jannis Benedikt From info at sten-net.de Fri Aug 26 00:55:14 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Fri, 26 Aug 2005 00:55:14 +0200 Subject: [Installit-dev] [Xfce4-commits] r17073 - in installit/trunk/I18n: . locale locale/de locale/fr In-Reply-To: <430E41FE.4040805@unix-ag.uni-siegen.de> References: <20050825215750.BBEFD1F70AD@espresso.foo-projects.org> <430E3F6B.8050705@unix-ag.uni-siegen.de> <430E3FDF.9070902@sten-net.de> <430E40B9.20307@sten-net.de> <430E41FE.4040805@unix-ag.uni-siegen.de> Message-ID: <430E4C52.6050203@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Benny, >> >>what do you think, would a file FILES in I18n/po/ would be ok for >>maintaining the source files relevant for the .po files or would it be >>better to scan for .py files in the helper script which generates the >>.mo files? > > > The usual way is to put a po/POTFILES there which contains a list of > relative paths to files which contain translatable strings. > Fine. I just committed an empty POTFILES file and wrote a tiny script which makes creating .po files easier (at least, I hope so): http://installit.xfce.org/trac.cgi/wiki/I18n - Jannis From info at sten-net.de Mon Aug 29 17:48:51 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Mon, 29 Aug 2005 17:48:51 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <430C68F3.3080105@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <430C663E.7070209@sten-net.de> <430C68F3.3080105@unix-ag.uni-siegen.de> Message-ID: <43132E63.4010200@sten-net.de> Hey Benny, >>>You can keep that in a single method init_gui() for each class, that'll >>>help to keep it in one place. It's better to have more code in this >>>case, so we can hopefully reach the "out-of-the-box"-goal one day. >> >>That's fine. Any tutorials/documentation on this in the web that you >>know of? > > > The "PyGTK 2.0 Tutorial" should do. we didn't find anything useful concerning glade code generators. The ones we found (glc and gladepyc) are outdated and can't deal with GTK2. Regards, Jannis From benedikt.meurer at unix-ag.uni-siegen.de Mon Aug 29 18:08:39 2005 From: benedikt.meurer at unix-ag.uni-siegen.de (Benedikt Meurer) Date: Mon, 29 Aug 2005 18:08:39 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <43132E63.4010200@sten-net.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <430C663E.7070209@sten-net.de> <430C68F3.3080105@unix-ag.uni-siegen.de> <43132E63.4010200@sten-net.de> Message-ID: <43133307.1070009@unix-ag.uni-siegen.de> Jannis Pohlmann wrote: > Hey Benny, > > >>>>You can keep that in a single method init_gui() for each class, that'll >>>>help to keep it in one place. It's better to have more code in this >>>>case, so we can hopefully reach the "out-of-the-box"-goal one day. >>> >>>That's fine. Any tutorials/documentation on this in the web that you >>>know of? >> >> >>The "PyGTK 2.0 Tutorial" should do. > > we didn't find anything useful concerning glade code generators. The > ones we found (glc and gladepyc) are outdated and can't deal with GTK2. I wasn't talking about a code generator, but to generate the code by hand. It's really easy to hack up the code once you have a design for the UI. > Regards, > Jannis Benedikt From info at sten-net.de Mon Aug 29 18:15:27 2005 From: info at sten-net.de (Jannis Pohlmann) Date: Mon, 29 Aug 2005 18:15:27 +0200 Subject: [Installit-dev] "package manager " becomes "InstallIt" In-Reply-To: <43133307.1070009@unix-ag.uni-siegen.de> References: <430C3640.8010007@sten-net.de> <430C551F.5070309@xfce.org> <430C5EF1.1020206@sten-net.de> <430C644B.8090700@unix-ag.uni-siegen.de> <430C663E.7070209@sten-net.de> <430C68F3.3080105@unix-ag.uni-siegen.de> <43132E63.4010200@sten-net.de> <43133307.1070009@unix-ag.uni-siegen.de> Message-ID: <4313349F.10503@sten-net.de> Benedikt Meurer schrieb: > Jannis Pohlmann wrote: > >>Hey Benny, >> >> >> >>>>>You can keep that in a single method init_gui() for each class, that'll >>>>>help to keep it in one place. It's better to have more code in this >>>>>case, so we can hopefully reach the "out-of-the-box"-goal one day. >>>> >>>>That's fine. Any tutorials/documentation on this in the web that you >>>>know of? >>> >>> >>>The "PyGTK 2.0 Tutorial" should do. >> >>we didn't find anything useful concerning glade code generators. The >>ones we found (glc and gladepyc) are outdated and can't deal with GTK2. > > > I wasn't talking about a code generator, but to generate the code by > hand. It's really easy to hack up the code once you have a design for > the UI. Aaaah, ok. That's sure, it won't be too much work. - Jannis