Re: mailcap next step
I'm attaching two scripts. One just converts 'old'
/usr/lib/mime/packages/ directory to 'new' one. Why I'll explain later.
Next is replacement for update-mime script to use 'new' format. It
generates full compatible mailcap file, but inserts just one application
(x and non x) for each mime type. I think this solution isn't worse than
original. Although this script has one *big* disadvantage... It's shell
script and it's very slow. I'm sorry but I don't know perl. Nevertheless
it can't be improved, it's just a sample.
Now, why I think my structure of files in /usr/lib/mime/packages is
better. It's very simple to take control of it. System wide script (my
update-mime2) looks at .default files for each type and puts into
mailcap. If it doesn't find defaults (admin didn't choose one) it puts
first from directory (such as old one). In conclusion, we see that we
generally don't loose usability but we're getting new one. Of course,
this script propably doesn't use all of original update-mime features,
because I don't even know them, but I can be improved.
In contrast the 'power' of this special directory structure is appearing
for user, not administrator. It's very easy to write a frontend to
select apps from that tree. For each type it can show user all
posibilities and extra show administrator suggestion (.default). Then in
*simple* way it'd generate ~/.mailcap file.
As we see, we don't loose usability, even compatibility. I replaced just
one script, and provide converter for temporary. Please, look at it, and
thinks is it interesting. Say rather about 'idealogic' solution, not
technically scripts, because they can be improved by someone, who's good
at it.
PS. I'm now using this on my computer and I don't have any problems. I
work know on a kind of frontend.
PS2. For tests, you can change directiories in scripts vars.
Regards,
Marcin.
--
.---, --: mcINEK :--
/ ,. \ ' T h e O w l s a r e n o t
| | ; ;W h a t T h e y S e e m . . . '
\ `._ /wrote on Debian GNU/Linux SID
#! /bin/bash
#
# This sctipt is a replacment for update-mime.
# It uses new format of /usr/lib/mime/packages dir.
#
# Author: mcINEK [EMAIL PROTECTED]
#
if [ -x /usr/sbin/update-mimedir ]; then
/usr/sbin/update-mimedir
fi
mime_dirs=/usr/lib/mime/packages
mailcap=/etc/mailcap
dirs=`find $mime_dirs -type d | sort`
if [ $mime_dirs == ]; then
echo Is /usr/lib/mime/packages using new format?
exit
fi
echo # File generated by update-mime2 script. $mailcap
echo $mailcap
for dir in $dirs; do
[ ! $dir == $mime_dirs ] || continue
dir=`echo $dir | awk -F\/ '{ print $NF}'`
cd $mime_dirs/$dir
# check, if there's any program
[ ! `ls` == ] || continue
# looking for non x program, sed to make sure if chosen only one
x_program=`ls x.*.default 2 /dev/null | sed q1`
if [ ! $x_program ]; then
# choose first available
x_program=`ls x.* 2 /dev/null | sed q1`
fi
# if not will use terminal program
# chech for a default term program
term_program=`ls --ignore='x.*' 2 /dev/null | grep .*.default | sed q1`
if [ ! $term_program ]; then
term_program=`ls --ignore='x.*' 2 /dev/null | sed q1`
fi
mime_type=`echo $dir | sed 's/\./\//'`
#echo X - $x_program T - $term_program
if [ $x_program ]; then
echo $mime_type; `cat $mime_dirs/$dir/$x_program` $mailcap
fi
if [ $term_program ]; then
echo $mime_type; `cat $mime_dirs/$dir/$term_program` $mailcap
fi
echo $mailcap
echo -n .
done
echo
#! /bin/bash
#
# This script converts old /usr/lib/mime/packages
# to new format.
#
# Author mcINEK [EMAIL PROTECTED]
#
mimedirs=/usr/lib/mime/packages
new_mimedirs=$mimedirs
files=`find $mimedirs -type f -maxdepth 0 | awk -F\/ '{ print $NF }'`
[ ! $files == ] || exit
for file in $files; do
while read line; do
[ ! $line == ] || continue
mime_type=`echo $line | awk -F\; '{ print $1 }'`
mime_dir=`echo $mime_type | sed 's/\//./'`
#echo $mime_type # choose one of two: this
echo -n . # or this
mkdir $new_mimedirs/$mime_dir 2 /dev/null
if [ `echo $line | grep DISPLAY` == ]; then
echo $line | awk -F' ' '{ for(i=2;i=NF;i++) {printf(%s ,$i)} }' \
$new_mimedirs/$mime_dir/$file
else
echo $line | awk -F' ' '{ for(i=2;i=NF;i++) {printf(%s ,$i)} }' \
$new_mimedirs/$mime_dir/x.$file
fi
done $mimedirs/$file
rm $mimedirs/$file 2 /dev/null
done
echo
signature.asc
Description: PGP signature
Re: mailcap next step
On Fri, 16 May 2003 12:05:17 +0200, mcINEK wrote: Next is replacement for update-mime script to use 'new' format. It generates full compatible mailcap file, but inserts just one application (x and non x) for each mime type. You obviously haven't read man mailcap.order? -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message
Re: mailcap next step
W licie z pi, 16-05-2003, godz. 13:05, Micha Politowski pisze: You obviously haven't read man mailcap.order? I've read, when you first time told me. It's just a step to provide that usability like my script. Please, look at this two opions objectively. Forget, that one of them is already implemented. First in administrator point of view. When you are administrator on non-your computer, you propably don't care about mime types, and you even don't change mailcap.order. If it's your machine, of course you can modify mailcap.order. But when you install apps or remove you must edit it manually. When you've got a lot of preferences mailcap.order is big and it's hard to find sth. Nevertheless, you propably use user account to work. And here is 'magic'. If you are advanced user (and of course you are :) you could copy /etc/mailcap to ~/.mailcap, sort it, and than just erase dubbling lines to chose that apps you want. It's ok, and it wasn't as much difficult (for you). However, imagine a user who doens't know a lot about all sfuff conencted with mime types (They are people like them too!!!). He propably won't know what to do. Here comes help. A frontend. Certainly, you can write a frontend parsing big file, and after hard work you propably will manage it to show info in simple way to user. But what for??? Now, it's so much easier to write a good, *fast* frontend in every language. Because, you've got clean (and soft :) directory structure with types. Besides, there's still a posibility to generate full mailcap like old one (if you want to). You can ask: why change sth? And I'd tell you: Because new solution is easier to improve, it's solid base to make any kind of apps making sth with mime. And if is not right now (I'm sure about it), we should improve it, or even find better. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
mailcap next step
Hello! I was wondering how to improve mailcap system to become useful. First step was to able mc use mailcap. Now, I want to make nautilus to use mailcap. And I have a few questions. 1. Where nautilus (gnome2?) keeps info about mime types? 2. (more complicated) Does run-mailcap differs x and non x applications? Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? Regards. Marcin -- .--, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 10:04:39AM +0200, mcINEK wrote: Hello! I was wondering how to improve mailcap system to become useful. First step was to able mc use mailcap. Now, I want to make nautilus to use mailcap. And I have a few questions. 1. Where nautilus (gnome2?) keeps info about mime types? 2. (more complicated) Does run-mailcap differs x and non x applications? If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts.
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. Yes, I've seen it. BUT... This is galeon entry in /etc/mailcap: text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html Even if I change it, to run links if not $DISPLAY it would be bad solution. User can't choose which browser use. In addition, it's another record from the same file. text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) text/html; if DISPLAY run x-www-browser else run www-browser that's all. When user want to change one of browsers just use update-alternatives --config. This mechanism may be applied not only for browser, but image-viewers etc. What do you think about that? (I hope you understanded me ;) Regards. Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 12:11:03PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 11:54, Wouter Verhelst pisze: If you already parsed mailcap into mc's configuration, you should've seen this (picking out a random one): application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test $DISPLAY != ; description=OpenOffice.org 1.0 Drawing; nametemplate=%.sxd Take extra care to the 'test' parameter. Could be posible run ie. links in mc and galeon in nautilus by the same run-mailcap command? If you can create a test to accomplish that, sure. Yes, I've seen it. BUT... This is galeon entry in /etc/mailcap: text/html; /usr/bin/galeon '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html Even if I change it, to run links if not $DISPLAY it would be bad solution. User can't choose which browser use. In addition, it's another record from the same file. text/html; /usr/bin/mozilla '%s'; description=HTML Text; test=test -n $DISPLAY; nametemplate=%s.html We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). Yes. The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) text/html; if DISPLAY run x-www-browser else run www-browser that's all. When user want to change one of browsers just use update-alternatives --config. Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. However, there's a better way. From mailcap(5): FILES $HOME/.mailcap:/etc/mailcap:/usr/share/etc/mailcap:/usr/local/etc/mail- cap -- default path for mailcap files. In other words: you can create a ~/.mailcap, with the same syntax as /etc/mailcap, and copy your preferred entries from /etc/mailcap there -- or create new ones. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpSpNlEjOEBj.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. But, does it eliminate my soluton? As you wrote later, user always can change /etc/mailcap. I didn't wonder how it would be on multi-users machines but I don't think it could be 'worse'. On the contrary, for one-user machines it will be very good and fast solution to make their programs runing apps like they want. The don't need to wonder what app will be starded, just that what they choose by update-alternatives. And also, this apps may be different for xwindows or console. What is more, everything will be doing automatically. I think it can be interesting. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 01:24:42PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 13:00, Wouter Verhelst pisze: Here's your error: if you do that, it's not the user who can change his browser, but the system administrator. Those two are not always the same. But, does it eliminate my soluton? As you wrote later, user always can change /etc/mailcap. I didn't wonder how it would be on multi-users machines but I don't think it could be 'worse'. On the contrary, for one-user machines it will be very good and fast solution to make their programs runing apps like they want. The don't need to wonder what app will be starded, just that what they choose by update-alternatives. And also, this apps may be different for xwindows or console. I really think it would be a bad idea to go the alternatives road here. If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. What is more, everything will be doing automatically. I think it can be interesting. We disagree, then. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpFd1QMfATGB.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: I really think it would be a bad idea to go the alternatives road here. But why? Could you give me any reasons? I've said why yes, so you tell why not ;] If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, 15 May 2003 12:11:03 +0200, mcINEK wrote: [...] We see a conflict. It doesn't matter how many browser user installed, always will be run galeon (it's above so it's first - am I right?). The best solution, I think, is that galeon (mozilla, etc) shouldn't provide a /etc/mailcap record, but just alternatives. And then in /etc/mailcap should be (just ONE) record, like (sorry, I don't know syntax) Assuming you think one setting for all users is enough, you already have a solution: man mailcap.order Otherwise ~/.mailcap is the way to go, as has been already suggested. -- Micha Politowski -- [EMAIL PROTECTED] Warning: this is a memetically modified message
Re: mailcap next step
On Thu, May 15, 2003 at 01:35:22PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 13:30, Wouter Verhelst pisze: I really think it would be a bad idea to go the alternatives road here. But why? Could you give me any reasons? I've said why yes, so you tell why not ;] Alternatives are meant for something else. I could want to run a small HTML viewer when I get a HTML-encoded mail, but could want to run mozilla or konqueror as my 'default' webbrowser, when an other application tries to run one. Yes, you could create /another/ alternative for /every/ MIME type in your mailcap, but that would bloat the alternatives system. Also, going the alternatives way would result in a *lot* of work (you'd have to remove all other mailcap entries, since they'd conflict with your work), and would not really be an improvement, since only the sysadmin could change preferences, and users would still be where they are today: having to copy lines from /etc/mailcap to ~/.mailcap. Worse; now they can copy lines; then, they'd have to edit them to be useful, else they'd /still/ run the sysadmin's preferences. Alternatives and mailcap are two different worlds. Please keep them separated. If you must, you could write a front-end that parses /etc/mailcap, and for a given MIME type, allows a user to pick the application of his/her choice; the front-end could then write that to ~/.mailcap. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpEjFHyNsreI.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 13:49, Wouter Verhelst pisze: Alternatives and mailcap are two different worlds. Please keep them separated. OK, so leave alternatives. It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. No, it doesn't. There can be more tjan one line describing the same mime type. And what then? Solving this problem will be sorting content of /usr/lib/mime/packages by appropiate types, such as: /usr/lib/mime/packages/text-html/mozilla, content (example): x,/usr/bin/mozilla /usr/lib/mime/packages/text-html/links content: text,/usr/bin/mozilla And on that base update-mime can generate /etc/mailcap. Of course if they'd be more browsers it only can choose one, but in the present time it's the same. If there'd be a types tree like that making front-end will make sense, otherwise no. User'd choose a program from that directory structure. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 02:13:32PM +0200, mcINEK wrote: It won't work, because the aren't any 'standards'. I don't have idea how make x/non-x choice from mailcap. I REALLY think alternatives could be good. It's done in there, all over the place! There's a 'test' option, which is meant to use a line conditionally; it's commonly used to test whether $DISPLAY is set, which is *exactly* what you need. No, it doesn't. There can be more tjan one line describing the same mime type. And what then? The first one will be used. Solving this problem will be sorting content of /usr/lib/mime/packages by appropiate types, such as: /usr/lib/mime/packages/text-html/mozilla, content (example): x,/usr/bin/mozilla /usr/lib/mime/packages/text-html/links content: text,/usr/bin/mozilla And on that base update-mime can generate /etc/mailcap. Of course if they'd be more browsers it only can choose one, but in the present time it's the same. You don't need to do that. Leave /etc/mailcap the way it is; system-wide preferences wrt default applications suck anyway :-) If there'd be a types tree like that making front-end will make sense, otherwise no. User'd choose a program from that directory structure. Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpcIpVqYnnIK.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. Of course, I can. But I don't understand why don't improve BAD mechanism. If sth is bad and doesn't pass our requests we should change it. Is update-mime a 'holy cow'? Nevertheless if it's just my opinion I won't argue and don't touch anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 02:46:34PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 14:30, Wouter Verhelst pisze: Uh. You can create such a tree in-memory, no? Parsing the file is not *that* hard. Of course, I can. But I don't understand why don't improve BAD mechanism. I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. If sth is bad and doesn't pass our requests we should change it. Is update-mime a 'holy cow'? Certainly not. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpM5KEp94Ay2.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. It's not perfect. Importand bugs are for me: * doesn't allow to choose what program use * it skip more than one application for one type Our task is to think, when it would be good, and what we're gonna do. Of course, we can leave it as it is now, but then we won't go further in making Debian better and more and more useful. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 03:35:33PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 15:23, Wouter Verhelst pisze: I fail to see why it would be bad. It's not perfect, but that's far from the same thing. Moreover, I think your ideas would make things worse, rather than better. It's not perfect. Importand bugs are for me: * doesn't allow to choose what program use Yes it does. Create a ~/.mailcap with the application of your choice for a given MIME-type at the top. My suggestion of a front-end was to create some application that would help $USER to manage ~/.mailcap. * it skip more than one application for one type That's actually the same thing as above, unless I don't understand what you mean. Our task is to think, when it would be good, and what we're gonna do. Of course, we can leave it as it is now, but then we won't go further in making Debian better and more and more useful. Please point me to where I said we should leave things as they are. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpLZhMBTb0Bp.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 15:42, Wouter Verhelst pisze: Yes it does. Create a ~/.mailcap with the application of your choice for a given MIME-type at the top. My suggestion of a front-end was to create some application that would help $USER to manage ~/.mailcap. I think it's good idea too. It could be done even now. But that what I'm trying to say, is we shouldn't use long ways. Solution you suggested is a 'little bubble' which you wan't stick to exist mechanism. I will work, however, it's just a bypass. It's a fine frontend to ulgy mechanism, which indeed doesn't work (if you have to parse generated file, it doesn't work). The clue is to think about efficient mechanism, which works globally and can be adapted by user in *simple* ways (not by a giant/slow script which parse conf file). Please point me to where I said we should leave things as they are. You didn't say that, but you want use *minimal* solution, which aren't always good. PS1. Windows are done this way. MS created took w2k and sticked more,more and more programmic 'bubbles' and created one big shit :) PS2. Maybe I wrote my definition of 'bubble': 'Bubble' is a short code, which you can put(stick) to original code without changing anything. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 04:05:28PM +0200, mcINEK wrote: Please point me to where I said we should leave things as they are. You didn't say that, but you want use *minimal* solution, which aren't always good. PS1. Windows are done this way. MS created took w2k and sticked more,more and more programmic 'bubbles' and created one big shit :) What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpMuVzjax1Di.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. But only if this API is good. If API is wrong and don't have support for new useful options, should be changed or improved. API is a solid, stable base for building additions, however, it must be simple and thought over. Besides, it's not such a basic feature, which requires change system core. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 04:53:32PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 16:38, Wouter Verhelst pisze: What's that supposed to mean? Doing that does have its advantages, too (such as you don't have to re-integrate everything with the new system). Granted, pushing that to extremes will end you up with an unworkable system with hundreds of incompatible API's. That's not what this does. But only if this API is good. It is, IMHO. If API is wrong and don't have support for new useful options, Who says it doesn't? should be changed or improved. API is a solid, stable base for building additions, however, it must be simple and thought over. Besides, it's not such a basic feature, which requires change system core. No, but lots of applications use it. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgph9f3pasBML.pgp Description: PGP signature
Re: mailcap next step
W licie z czw, 15-05-2003, godz. 17:06, Wouter Verhelst pisze: It is, IMHO. IMHO not, because doesn't provide things I mentioned before. Who says it doesn't? Like above. No, but lots of applications use it. Yes, that's true. Nevertheless, it shouldn't be a brake in improving it. Regards, Marcin -- .---, --: mcINEK :-- / ,. \ ' T h e O w l s a r e n o t | | ; ;W h a t T h e y S e e m . . . ' \ `._ /wrote on Debian GNU/Linux SID signature.asc Description: PGP signature
Re: mailcap next step
On Thu, May 15, 2003 at 06:53:51PM +0200, mcINEK wrote: W li?cie z czw, 15-05-2003, godz. 17:06, Wouter Verhelst pisze: It is, IMHO. IMHO not, because doesn't provide things I mentioned before. Who says it doesn't? Like above. You can just add field types, if required. It won't do any harm, while it would create possibilities. Which is to say that there is space for improvement. No, but lots of applications use it. Yes, that's true. Nevertheless, it shouldn't be a brake in improving it. 'to improve' is not the same thing as 'to replace'. If you want to improve it, be my guest. I won't stop you; on the contrary. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts.
