Re: Debian Light Desktop - meta package
* Wed 2006-06-07 Axel Beckert * Message-Id: 20060607001535.GT3066 AT fsinfo.cs.uni-sb.de > Hi! > >> I'm creating a meta package for install a lite desktop for old >> machines with poor hardware. > > Hey, that's a really cool idea! Debian is one of the last modern (and > not specialised) Linux distribution feasible for old and slow > hardware, especially old PCs. But Sarge already made a big step away > from old PCs (e.g. by dropping XFree86 3.3 and requiring 32 Megs of > RAM for installation -- Woody needed only 12 Megs) so I'm really happy > to see that others try to take the cudgels for Debian on old hardware > too. FYI, I've already have a running a project to provide a very light, very low profile Desktop for Debian. The project is ready to install[*] and it has been tested for old harware running 64M/166 (even lower) needs. The project page is at: http://debian.cante.net/stem The extra packages currently used are optional and some that are missing are being ported to Debian. At the end of opening page you will find listing of programs used for the desktop. http://debian.cante.net/stem/package.lst The WM choices currently are: - Jwm window manager (very light) - Fvwm95 (the "standard look"), moderate memory consumption. You will also find study on programs that were evaluated to build up the desktop from pictures of memory consumption graphs. http://debian.cante.net/stem/manual http://debian.cante.net/stem/faq Suggestions how to eventually be included it in Debian, please comment how this could be done. I'm not a DD yet. Jari - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [*] The bugs are being ironed out, but in general it's ready for the prime time. Repository deb http://debian.cante.net/debian unstable main deb-src http://debian.cante.net/debian unstable main There is automatic install script (asks few questions) wget -qN http://debian.cante.net/stem/netinstall.sh sh netinstall.sh [--help] or install can be done manually (for expert only) apt-cache search ^stem- apt-cache show -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
* Tue 2006-06-13 Josselin Mouette * Message-Id: 1150231486.17236.21.camel AT utena.localnet > Le lundi 12 juin 2006 à 20:44 +0200, Kurt Roeckx a écrit : > >> I think you're not very clear in what you're asking, so I'm going >> to try and explain what I think you said. >> >> If you open a file in a file browser, or you open it thru a web >> browser or something, it might have a mime type assosiated with >> it. So what I think you suggest is that based on the mime-type >> we start an application that should be able to handle that >> mime-type. > > This is what the Freedesktop.org MIME database achieves. No need to > reinvent what is already a widespread standard. The proposal here talks about differnt thing, but indirectly concerns the mime types, which are used to associate actions to certain file extensions. Command line usage (or from Window manager menu): call: x-spreadsheet instead of call: name-of-the-program-that-user-may-not-have The mime types benefits from the alternatives framework too, whcih currently use hard coded names (programs that user may not have installed: application/msexcel; oocalc '%s ... Whereas the entried would better read: application/msexcel; x-spreadsheet '%s ... And the user selected program were configured with (and programs available would register themselves into): update-alternatived --config x-spreadsheet Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
* Wed 2006-06-14 Hendrik Sattler >> >> The proposal here talks about differnt thing, but indirectly concerns >> the mime types, which are used to associate actions to certain file >> extensions. > > Why not have something that starts the proper program according to the given > mimetype? E.g.: > x-mime-handler application/whatever > > This program can make use of the .desktop files. If the .desktop files cannot > do this, yet, the standard for them should be extended to make it possible > instead of inventing yet another. Hm. How does that work from command line? Or from X programs that have fields like: Run program: _ As I understand, these require the name of executable and the alternatives system does that. Like providing sensible-editor I'm not familiar with the .desktop files but I assume they belong only to environments like Gnome and KDE. How would they be used with small window managers, that simply contain "plug menu item name here, call program" approach? > Note that the alternative-System has one major drawback: it reflects the > choice of the administrator only, not the one of the user. And those two > _often_ do not match. 90% of the Linux installations or more are personal PCs. For corporate wide installations, the choice of fixed programs is preferred. I don't see real obstacle here. Granted that the alternatives system should be extended to look for $HOME/debian/alternatives Before checking /etc/laternatives Perhaps I should file a wishlist for it. > Another problem is the missing option compatibility between all of those > programs and thus only offers very limited usage of the used programs. And it > hides the problem that you have to get used to a program to efficiently use > it, e.g. KWord has many differences when compared to OpenOffice Writer. I believe the need to pass options to programs is beyond the scope of this. > And the last point: you have icons on a desktop (or in a menu or whatever) > and > don't have to remember strange names, anyway. Users that start everything > from a shell usually do not use such (mainly mouse-operated) programs. There are 20+ window managers out there that do not have icons. Not everybody is capable of running KDE/Gnome that drain all memory from average systems ( 400Mhz .. 1500Mhz). We can forget KDE an Gnome (and XFCE?) altogether from this picture, because they are completely self contained and any invention in there cannot be used outside of them. The proposal talks about providing framework for Window managers that do not have sophisticated program control mechanism. This also means that it is impossible to ship reasonable default menus, when there is no infrastructure in place to use. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...
* Thu 2006-06-15 Bernhard Link * Message-Id: 20060615123501.GA11774 AT login.informatik.uni-freiburg.de > * Jari Aalto+usenet [060615 12:32]: >> The features would be those proposed at the beginning. Examples: >> >> x-mime-handler --run x-file-manager /home/foo >> x-mime-handler --run x-spreadsheet this.xls > > What is wrong with: > > run-mailcap --action=view application/vnd.ms-excel:this.xls > > or shorter: > > see application/vnd.ms-excel:this.xls > > or even shorten (if its type can be detected automatically correctly and > one has no other information:) > > see this.xls Good. I just wasn't familiar with run-mailcap's capabilities. I'll update the proposal after comments. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
