mactextoolbox-talk Mailing List for Mac TeX Toolbox (Page 5)
Status: Planning
Brought to you by:
jlaurens
Menu
▾
▴
mactextoolbox-talk — Discussion for Macintosh developers for TeX Tools
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(23) |
Jul
(81) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jer...@u-...> - 2005-06-28 06:57:45
|
Le 27 juin 05, =E0 22:06, Maarten Sneep a =E9crit :
> On 27 Jun 2005, at 16:21, J=E9r=F4me Laurens wrote:
>
>> Le 24 juin 05, =E0 22:56, Maxwell, Adam R a =E9crit :
>>
>>> I've tried setting xattrs and moving a text file onto an NFS volume;=20=
>>> the attributes were preserved when moving them back and forth, which=20=
>>> is good. However, opening and saving the file in TextEdit lost the=20=
>>> attributes, which is unfortunate.
>>>
>>
>> Indeed.
>>
>> I guess mail will not send this xattrs too...
>
> or an ftp transfer, or http for that matter. I'm not sure about=20
> sftp/scp though, they might support xattrs. But I guess there are a=20
> thousand ways to loose your metadata (cue music here).
>
>> I think the best policy is to never rely on such attributes.
>
> I wouldn't put it that way: when present, they can be trusted, when=20
> not available they must be reconstructed somehow.
They can be trusted as long as the end user keeps the control in its=20
hands.
The most critical part concerns the text encoding because it can=20
definitely break the source.
>
>> Also, for extended file attributes, the best way seems to consider at=20=
>> the same time xattrs, resource fork and external location when=20
>> possible.
>
> I assume with external location you means something like a project=20
> file or a wrapper. Warning: attempt to get you to write an article=20
> ahead: Could you create some overview of what your idea of a TeX=20
> wrapper is (and maybe more importantly: what it isn't. I think this=20
> article should address the context in which wrappers will be used (in=20=
> your vision)).
Give me one more hour a day and I can do it...
>
>> That way, we hardly break the whole metadata design when moving files=20=
>> around, and can retrieve at least partly the metadata.
>
> I'm going to make a bold statement here: all the metadata is already=20=
> in the TeX sources, and can be reconstructed from there. (why are we=20=
> getting so excited about it then ;)
>
Except the language used and list of known words, window size and=20
position, selected text ranges, magnification, page displayed, page=20
diplay mode and so on.
In short, everything that makes the difference between a tool and a=20
good tool;-)
> - The encoding is indicated in the master file=20
> \usepackage[latin1]{inputenc} is fairly unambiguous, and Context has=20=
> similar statements.
> - The master file can be found by searching through a directory tree=20=
> (including looking 'up' the tree), again this works for both LaTeX,=20
> TeX and Context. It may be relatively slow, and I know of cases where=20=
> it fails (where a file could be processed stand-alone, or included, or=20=
> documents that can be included in more than a single master. The=20
> current metadata approaches will not handle those cases either).
> - One can try to determine the engine by looking at the command=20
> sequences: \begin{figure} is indicative of LaTeX, \startfigure hints=20=
> at context (though its multiple input language support makes things a=20=
> bit harder).
>
> OK, doing away with metadata is not a good idea, but not all is lost=20=
> if they become separated. At the moment I'm still in favour of using=20=
> comments to indicate some key elements (character encoding, an=20
> indication of the master file, the core engine, and then some) or a=20
> property-list file to hold that info (the latter may become out of=20
> sync, so that is an issue). For things like navigation markers, I=20
> strongly prefer the in-source option, because it allows me to put a=20
> marker in very quickly.
I am strongly against using TeX comments for that purpose, despite I=20
did it myself for iTM.
Except if they conform to an official, clear, publicly available=20
specification, and eventually become part of the language.
Before implementing the inline navigation markers in iTM, I asked the=20
Mac OS X TeX list about the syntax, in order not to be preemptive. The=20=
only answer I got came from Gerben, who preferred to use identifiers=20
dedicated to applications. So I implemented something clearly targeted=20=
to iTM. If you add scientific words, emacs, auctex, TeXShop and others,=20=
your source will contain a lot of useless things...
Moreover, TeX is already complicated, such that adding new rules should=20=
require great care.
What you prefer is to put a marker in very quickly (so do I) but this=20
has nothing to do with inline commenting or not. This has to do with=20
the user interface provided by your text editor. You are confusing the=20=
user interface and the underlying data model.
It is very easy to write down a text editor that makes you believe that=20=
marks are just inline comments, whereas they are in fact stored outside=20=
the text stream. On the other hand, it is also very easy to write a=20
text editor that hides those inline comments in the displayed text=20
stream an replace them by a small icon in the left margin (like xcode=20
stop markers). These are just hints to let you imagine how can be an=20
efficient user interface.
What you need is typing the mark name, add one or two keystrokes as=20
shortcut, then clearly identify the position of the mark in the window.=20=
Do you really need to see the mark name exactly where it stands? No,=20
you only need to see it in the mark menu. So the user interface does=20
not really have to expose the mark name, something like a tooltip is=20
sufficient.
Finally, if you use inline comments for that purpose, adding or=20
removing a mark takes place in the text undo stack. Some people might=20
feel uncomfortable with that.
So, here might be the subject of the second mac tex toolbox texnical=20
note: official inline comments.
|
|
From: Maarten S. <maa...@xs...> - 2005-06-27 20:06:30
|
On 27 Jun 2005, at 16:21, J=E9r=F4me Laurens wrote:
> Le 24 juin 05, =E0 22:56, Maxwell, Adam R a =E9crit :
>
>> I've tried setting xattrs and moving a text file onto an NFS =20
>> volume; the attributes were preserved when moving them back and =20
>> forth, which is good. However, opening and saving the file in =20
>> TextEdit lost the attributes, which is unfortunate.
>>
>
> Indeed.
>
> I guess mail will not send this xattrs too...
or an ftp transfer, or http for that matter. I'm not sure about sftp/=20
scp though, they might support xattrs. But I guess there are a =20
thousand ways to loose your metadata (cue music here).
> I think the best policy is to never rely on such attributes.
I wouldn't put it that way: when present, they can be trusted, when =20
not available they must be reconstructed somehow.
> Also, for extended file attributes, the best way seems to consider =20
> at the same time xattrs, resource fork and external location when =20
> possible.
I assume with external location you means something like a project =20
file or a wrapper. Warning: attempt to get you to write an article =20
ahead: Could you create some overview of what your idea of a TeX =20
wrapper is (and maybe more importantly: what it isn't. I think this =20
article should address the context in which wrappers will be used (in =20=
your vision)).
> That way, we hardly break the whole metadata design when moving =20
> files around, and can retrieve at least partly the metadata.
I'm going to make a bold statement here: all the metadata is already =20
in the TeX sources, and can be reconstructed from there. (why are we =20
getting so excited about it then ;)
- The encoding is indicated in the master file \usepackage[latin1]=20
{inputenc} is fairly unambiguous, and Context has similar statements.
- The master file can be found by searching through a directory tree =20
(including looking 'up' the tree), again this works for both LaTeX, =20
TeX and Context. It may be relatively slow, and I know of cases where =20=
it fails (where a file could be processed stand-alone, or included, =20
or documents that can be included in more than a single master. The =20
current metadata approaches will not handle those cases either).
- One can try to determine the engine by looking at the command =20
sequences: \begin{figure} is indicative of LaTeX, \startfigure hints =20
at context (though its multiple input language support makes things a =20=
bit harder).
OK, doing away with metadata is not a good idea, but not all is lost =20
if they become separated. At the moment I'm still in favour of using =20
comments to indicate some key elements (character encoding, an =20
indication of the master file, the core engine, and then some) or a =20
property-list file to hold that info (the latter may become out of =20
sync, so that is an issue). For things like navigation markers, I =20
strongly prefer the in-source option, because it allows me to put a =20
marker in very quickly.
> Needs some further thinking before implementation.
Certainly, if only because you can bet that Apple will deliver some =20
Cocoa interface for xattrs later on. We should certainly strive to =20
keep it modularised, so that it can be replaced easily with whatever =20
Apple delivers.
Maarten=
|
|
From: <jer...@u-...> - 2005-06-27 14:23:00
|
Le 24 juin 05, =E0 22:56, Maxwell, Adam R a =E9crit : >> On Jun 24, 2005, at 03:55, J=E9r=F4me Laurens wrote: >> >> >>> I don't know how many developers are there but at least we can=20 >>> start a discussion. >>> >>> Tiger now supports xattrs BSD feature, and it is -really- a major=20 >>> step forward. >>> To play with xattrs, you can download >>> <http://www.macs.hw.ac.uk/~rpointon/osx/xattr.html> >>> I don't know how far those xattrs are linked to their file when=20 >>> moving around the internet but things are promising. > > I've tried setting xattrs and moving a text file onto an NFS volume;=20= > the attributes were preserved when moving them back and forth, which=20= > is good. However, opening and saving the file in TextEdit lost the=20 > attributes, which is unfortunate. Indeed. I guess mail will not send this xattrs too... I think the best policy is to never rely on such attributes. Also, for extended file attributes, the best way seems to consider at=20 the same time xattrs, resource fork and external location when=20 possible. That way, we hardly break the whole metadata design when moving files=20 around, and can retrieve at least partly the metadata. Needs some further thinking before implementation. > > Adam > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk > --=20 > Mactextoolbox-talk mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk > |
|
From: Maxwell, A. R <ada...@pn...> - 2005-06-24 20:56:59
|
> On Jun 24, 2005, at 03:55, J=E9r=F4me Laurens wrote: > > >> I don't know how many developers are there but at least we can =20 >> start a discussion. >> >> Tiger now supports xattrs BSD feature, and it is -really- a major =20 >> step forward. >> To play with xattrs, you can download >> <http://www.macs.hw.ac.uk/~rpointon/osx/xattr.html> >> I don't know how far those xattrs are linked to their file when =20 >> moving around the internet but things are promising. I've tried setting xattrs and moving a text file onto an NFS volume; =20 the attributes were preserved when moving them back and forth, which =20 is good. However, opening and saving the file in TextEdit lost the =20 attributes, which is unfortunate. Adam= |
|
From: Maxwell, A. R <ada...@pn...> - 2005-06-24 15:51:35
|
On Jun 24, 2005, at 03:55, J=E9r=F4me Laurens wrote: > I don't know how many developers are there but at least we can =20 > start a discussion. > > Tiger now supports xattrs BSD feature, and it is -really- a major =20 > step forward. > To play with xattrs, you can download > <http://www.macs.hw.ac.uk/~rpointon/osx/xattr.html> > I don't know how far those xattrs are linked to their file when =20 > moving around the internet but things are promising. > > Using xattrs, you can store any kind of meta data that are not =20 > strictly necessary but makes life so easy. > You can also store vital data such as character encoding. > I can see here another mean to store the TeX source(s) of a pdf =20 > file with the output, without forgetting the pdfsync file... That would be cool! I don't see a size limit on the xattrs, either. > AFAIK, the actual context is: > - Adam made a draft cocoa bridge Which is just a category on NSFileManager that wraps the xattr calls; =20= it needs a bit more work to be really useful. > - there is a pythonmac bridge too > - some links from google about EAs (Extended attributes) and ACLs =20 > (Access Control List) related to the linux kernel > - we already discussed a bit on the mactex list concerning =20 > specifications, but we should edit some general usage specifications. > - I did not find anything about a concrete use of xattrs to store =20 > the character encoding, The closest thing I've found is from the man page for getattrlist(2): "ATTR_CMN_SCRIPT (read/write) A text_encoding_t containing a text encoding hint for =20 the file system object's name. It is included to facilitate the =20 lossless round trip conversion of names between Unicode and =20 traditional Mac OS script encodings. The values are defined in =20 <CarbonCore/TextCommon.h>. File systems that do not have an =20 appropriate text encoding value should return =20 kTextEncodingMacUnicode. See DTS Q&A 1173 File Manager Text Encoding =20 Hints"." This appears to be the encoding of the file name itself, though; I'm =20 not familiar with the Carbon resource fork APIs, but maybe Jon Guyer =20 has some insight on this. We could probably just agree on encoding keys to be used by members =20 of this project, such as net-sourceforge-mactextoolbox-=20 characterencoding, and store either the IANA name (doesn't exist for =20 NSNonlossyASCIIStringEncoding, though) or the encoding constant itself. --=20 Adam= |
|
From: Simon S. <si...@si...> - 2005-06-24 14:35:41
|
Hi, everybody, just wanted to let you know that I'm on this mailing list =20 as well (digest only). I've been a regular on the BibDesk dev mailing =20= list, pesting the programmers with bug reports and feature requests =20 all the time. I'm not a programmer and I don't know if I can be of =20 any real help here but I will staying on the list for a while to see =20 how it develops. I just wanted to say that I think this is a great thing, projects =20 exchanging ideas and working together. The OSX LaTeX community is =20 terrific, a real role model for OS development and I'm sure we'll see =20= cool things coming from this project. simon -- Simon Spiegel Mutschellenstr. 97 8038 Z=FCrich Telephon: ++41 43 535 81 71 Mobophon: ++41 76 459 60 39 http://www.simifilm.ch "I have never been certain that the moral of the Icarus myth is, as =20 is generally accepted, 'don't fly too high', or whether it might also =20= be thought of as: 'forget about the wax and feathers, and do a better =20= job on the wings." Stanley Kubrick |
|
From: Jon G. <jg...@hi...> - 2005-06-24 13:10:20
|
On Jun 24, 2005, at 5:02 AM, J=E9r=F4me Laurens wrote: > and I am hardly focusing on iTeXMac, the next generation. In English, being the logical joy that it its, "hardly focusing" is the=20= polar opposite of "focusing hard". Of course, maybe that's what you meant! 8^) |
|
From: <jer...@u-...> - 2005-06-24 11:08:22
|
Le 24 juin 05, =E0 12:26, Massimiliano Gubinelli a =E9crit : > > > On 24 Jun 2005, at 12:14, J=E9r=F4me Laurens wrote: > >> HI, >> >> If we happen to agree on cocoa code, objects names could be MTT=20 >> prefixed? >> > > why not just TT (since M is somewhat implicit in Cocoa...). > > Well, not on gnustep;-) I am assuming that the probability to have MTT already used is far=20 smaller than for TT. With google, MTT+cocoa gives 710 answers, whereas TT+Cocoa gives quite=20= 100x more. I know this is meaningless but it may help. Anyway, that's not so important as long as no code is publicly=20 available.= |
|
From: <jer...@u-...> - 2005-06-24 10:56:53
|
I don't know how many developers are there but at least we can start a discussion. Tiger now supports xattrs BSD feature, and it is -really- a major step forward. To play with xattrs, you can download <http://www.macs.hw.ac.uk/~rpointon/osx/xattr.html> I don't know how far those xattrs are linked to their file when moving around the internet but things are promising. Using xattrs, you can store any kind of meta data that are not strictly necessary but makes life so easy. You can also store vital data such as character encoding. I can see here another mean to store the TeX source(s) of a pdf file with the output, without forgetting the pdfsync file... AFAIK, the actual context is: - Adam made a draft cocoa bridge - there is a pythonmac bridge too - some links from google about EAs (Extended attributes) and ACLs (Access Control List) related to the linux kernel - we already discussed a bit on the mactex list concerning specifications, but we should edit some general usage specifications. - I did not find anything about a concrete use of xattrs to store the character encoding, Here is what could be done 1 - make a low level cocoa bridge over all the xattrs functions, using an NSFileManager category (Adam's already did quite all the job) 2 - Define the xattr convention to be used, namespace, contents, formats... The most important is the character encoding when it can't be hard coded in the text. Here is the material for an article on the mac tex toolbox web site 3 - Make an attributes wrapper, that uses the above bridge on tiger and standard resources on previous systems (I am starting that as a cluster with two concrete subclasses: one for tiger and one for the others) That's all for the moment: I have to make iTM2 work! |
|
From: Massimiliano G. <mg...@ma...> - 2005-06-24 10:26:55
|
On 24 Jun 2005, at 12:14, J=E9r=F4me Laurens wrote: > HI, > > If we happen to agree on cocoa code, objects names could be MTT =20 > prefixed? > why not just TT (since M is somewhat implicit in Cocoa...). best, max > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli= ck > --=20 > Mactextoolbox-talk mailing list > Mac...@li... > https://lists.sourceforge.net/lists/listinfo/mactextoolbox-talk > |
|
From: <jer...@u-...> - 2005-06-24 10:16:28
|
HI, If we happen to agree on cocoa code, objects names could be MTT prefixed? |
|
From: <jer...@u-...> - 2005-06-24 10:09:00
|
Hello guys I finally got subscribed! It's hot here, I'd better go to the sea, unfortunately it's more than 500 km from my seat so I will work for a while... I don't know if it is relevant in such a targeted list but let me give a few words of introduction I have just finished my year in teaching mathematics at Dijon university, and I am hardly focusing on iTeXMac, the next generation. PS: marteen, please ignore the warning generated by the list server, it was due to my short mind... |
|
From: Maarten S. <maa...@xs...> - 2005-06-23 21:04:38
|
On 23 Jun 2005, at 21:48, Michael McCracken wrote: > On 6/23/05, Maxwell, Adam R <ada...@pn...> wrote: > >> Maybe Mike's research on Apple Help writing would be useful for an >> article :). > > Good idea - we could share what we've learned so far, and =20 > considering that > the tools we ended up with are similar to tex and at least > open-source, it might make sense to share them with the community. > > For reference, I started out here: > http://michael-mccracken.net/blog/blosxom.pl/computers/mac/=20 > programming/singleSourceDocs.html > and made a bunch of posts to bibdesk-dev with further info. > > If you like, I could turn those various posts into a single article > aimed at the toolbox's audience. That would be really nice. There are some templates available from =20 the articles page, if you want those. >>> I'll probably add some of my own scripts to the file download >>> section or at least to the CVS repository. Private advice on how to >>> maintain a sourceforge project is appreciated. >> >> Or perhaps public advice on this? Mike and J=E9r=F4me have been >> maintaining sourceforge projects longer than the rest of us, and I'd >> be interested in any tips as well. > > Hmm, tips - well, for starters I'd suggest making sure you disable > anything you aren't planning to use - the screenshots archive is > particularly useless, IMHO, and if you have lists you may not also > want forums. > > Another tip is that anything you can do to get automatic notifications > instead of having to revisit the website is worth your time to set up. > Make sure you have new tracker items send email somewhere you check - > BibDesk has -bugs and -rfes mailing lists that catch all new items, > even if they're not assigned to someone. If you don't do this and > nobody assigns anyone to a new item, that item falls through the > cracks until the next time you go browse the tracker's web > interface... > > Also, I have ssh-keys set up for my sourceforge account, and thank > god. I would surely hate life if I had to type in my password every > time I used CVS for BibDesk... > The info about that is here: > http://sourceforge.net/docman/display_doc.php?docid=3D3088&group_id=3D1 > > I'll try to think of others, but that's all I've got for now. Thanks for this, and thanks for the text on BibDesk. I'll add the =20 discription some time after the weekend. Maarten= |
|
From: Maxwell, A. R <ada...@pn...> - 2005-06-23 20:14:07
|
On Jun 23, 2005, at 12:42, Maarten Sneep wrote: > On 23 Jun 2005, at 16:12, Adam R. Maxwell wrote: > > >> Please add TCOBrowser to the list of participating projects: =20 >> <http://tcobrowser.sf.net/>, BSD license; let me know what info =20 >> you want, if any. I've been sort of hesitant to advertise it, =20 >> since it was the first Cocoa project I wrote from scratch, and =20 >> parts of it are fairly ugly. >> > > I've updated the about page on the web-site with information of =20 > what I need: I'll get that to you as soon as I find it. >> I don't have web pages or anything for my BibTeX/DVI spotlight =20 >> importers, and I don't think they're worth setting up a sf.net =20 >> project for, but the source is available on request (BSD =20 >> license). (I could open up my cvs server, but I don't want the =20 >> maintenance hassle). >> > > Once I figure out, and find the time to do it, I'll add some of my =20 > smaller project scripts to the CVS of this project. After that I =20 > can add some other smaller projects there as well, and the =20 > importers would be interesting for these purposes. > > >> Oh, I could also contribute my NSFileManager category for extended =20= >> attributes if anyone besides J=E9r=F4me is interested :). Maybe =20 >> BibDesk should start storing character encoding in xattrs? >> > > See my previous remark: either as a normal file download, or in the =20= > CVS for the project. Sunchronisation between your and my tree would =20= > be a bit of a mess, but otherwise I think this is the project to =20 > store such small code libraries. SourceForge did a good job importing my tcobrowser tree (which I had =20 in my local CVS) with all revisions intact. <http://sourceforge.net/=20 docman/display_doc.php?docid=3D768&group_id=3D1#existingcvsimport> has =20= more info, but basically you just submit a tarball with a support =20 request and they do all the work. If we can add the Spotlight =20 importers, I'd just let my own CVS bitrot, and any active work could =20 take place in the toolbox cvs. Adam |
|
From: Michael M. <mic...@gm...> - 2005-06-23 19:58:49
|
> I would like to have your description as well: just a short > description to add to the list (what is BibDesk, why should you use > it, and what development tasks could use some extra hands). I suggest just using this from the http://bibdesk.sourceforge.net website: BibDesk is a graphical BibTeX-bibliography manager for Mac OS X. BibDesk is designed to help organize and use bibliographic databases in BibTeX .bib format. In addition to manual typing, BibDesk lets you drag & drop or cut & paste .bib files into the bibliographic database and automatically opens files downloaded from PubMed. BibDesk also keeps track of electronic copies of literature on your computer and allows for searching your database through several keys. And as far as what development tasks could use extra hands, for now I'd say the following, although if we get a lot of response we might put a list of projects up on the wiki: BibDesk is an active project that makes full use of its bug and feature request trackers. If you want to help out, find or create a feature request you want to implement or a bug you want to fix, join the developer mailing list[1] and talk to us! Non-coding help that is always appreciated is translation, web site and wiki improvements, documentation, testing, etc... [1]:http://lists.sourceforge.net/lists/listinfo/bibdesk-develop How's that sound? -mike --=20 Michael McCracken UCSD CSE PhD Student San Diego Supercomputer Center http://www.cse.ucsd.edu/~mmccrack/ |
|
From: Michael M. <mic...@gm...> - 2005-06-23 19:48:28
|
On 6/23/05, Maxwell, Adam R <ada...@pn...> wrote: >=20 > On Jun 22, 2005, at 15:04, Maarten Sneep wrote: >=20 > >> Let me know what else is involved, and thanks for the work > >> organizing this. > >> > > > > At the moment: not much: I lack the time right now. I'll add new > > articles as I receive them, and the mailing list will go forward. >=20 > Maybe Mike's research on Apple Help writing would be useful for an > article :). Good idea - we could share what we've learned so far, and considering that= =20 the tools we ended up with are similar to tex and at least open-source, it might make sense to share them with the community. For reference, I started out here: http://michael-mccracken.net/blog/blosxom.pl/computers/mac/programming/sing= leSourceDocs.html and made a bunch of posts to bibdesk-dev with further info. If you like, I could turn those various posts into a single article aimed at the toolbox's audience. =20 > > I'll probably add some of my own scripts to the file download > > section or at least to the CVS repository. Private advice on how to > > maintain a sourceforge project is appreciated. >=20 > Or perhaps public advice on this? Mike and J=E9r=F4me have been > maintaining sourceforge projects longer than the rest of us, and I'd > be interested in any tips as well. Hmm, tips - well, for starters I'd suggest making sure you disable anything you aren't planning to use - the screenshots archive is particularly useless, IMHO, and if you have lists you may not also want forums. Another tip is that anything you can do to get automatic notifications instead of having to revisit the website is worth your time to set up. Make sure you have new tracker items send email somewhere you check - BibDesk has -bugs and -rfes mailing lists that catch all new items, even if they're not assigned to someone. If you don't do this and nobody assigns anyone to a new item, that item falls through the cracks until the next time you go browse the tracker's web interface... Also, I have ssh-keys set up for my sourceforge account, and thank god. I would surely hate life if I had to type in my password every time I used CVS for BibDesk... The info about that is here:=20 http://sourceforge.net/docman/display_doc.php?docid=3D3088&group_id=3D1 I'll try to think of others, but that's all I've got for now. -mike --=20 Michael McCracken UCSD CSE PhD Student San Diego Supercomputer Center http://www.cse.ucsd.edu/~mmccrack/ |
|
From: Maarten S. <maa...@xs...> - 2005-06-23 19:42:23
|
On 23 Jun 2005, at 16:12, Adam R. Maxwell wrote: > Please add TCOBrowser to the list of participating projects: =20 > <http://tcobrowser.sf.net/>, BSD license; let me know what info you =20= > want, if any. I've been sort of hesitant to advertise it, since it =20= > was the first Cocoa project I wrote from scratch, and parts of it =20 > are fairly ugly. I've updated the about page on the web-site with information of what =20 I need: + the web-address where I can find your project, + the full icon of your application, in =93.png=94 format, + the text that should appear next to the icon on the participating =20 projects page. This text should briefly describe what your application does, what is =20= special about it, and what the future plans are. This description is =20 geared towards developers, so advertise why other developers should =20 take a look at the sources (they might find something of interest =20 there). Please send the mail from the address you used to subscribe to the =20 mailing list, that allows me to check the subscription. > I don't have web pages or anything for my BibTeX/DVI spotlight =20 > importers, and I don't think they're worth setting up a sf.net =20 > project for, but the source is available on request (BSD license). =20= > (I could open up my cvs server, but I don't want the maintenance =20 > hassle). Once I figure out, and find the time to do it, I'll add some of my =20 smaller project scripts to the CVS of this project. After that I can =20 add some other smaller projects there as well, and the importers =20 would be interesting for these purposes. > Oh, I could also contribute my NSFileManager category for extended =20 > attributes if anyone besides J=E9r=F4me is interested :). Maybe =20 > BibDesk should start storing character encoding in xattrs? See my previous remark: either as a normal file download, or in the =20 CVS for the project. Sunchronisation between your and my tree would =20 be a bit of a mess, but otherwise I think this is the project to =20 store such small code libraries. Maarten |
|
From: Maxwell, A. R <ada...@pn...> - 2005-06-23 18:43:55
|
On Jun 22, 2005, at 15:04, Maarten Sneep wrote: >> Let me know what else is involved, and thanks for the work =20 >> organizing this. >> > > At the moment: not much: I lack the time right now. I'll add new =20 > articles as I receive them, and the mailing list will go forward. Maybe Mike's research on Apple Help writing would be useful for an =20 article :). > I'll probably add some of my own scripts to the file download =20 > section or at least to the CVS repository. Private advice on how to =20= > maintain a sourceforge project is appreciated. Or perhaps public advice on this? Mike and J=E9r=F4me have been =20 maintaining sourceforge projects longer than the rest of us, and I'd =20 be interested in any tips as well. regards, Adam= |
|
From: Adam R. M. <ama...@ma...> - 2005-06-23 14:12:42
|
Maarten, Please add TCOBrowser to the list of participating projects: <http://=20 tcobrowser.sf.net/>, BSD license; let me know what info you want, if =20 any. I've been sort of hesitant to advertise it, since it was the =20 first Cocoa project I wrote from scratch, and parts of it are fairly =20 ugly. I don't have web pages or anything for my BibTeX/DVI spotlight =20 importers, and I don't think they're worth setting up a sf.net =20 project for, but the source is available on request (BSD license). =20 (I could open up my cvs server, but I don't want the maintenance =20 hassle). Oh, I could also contribute my NSFileManager category for extended =20 attributes if anyone besides J=E9r=F4me is interested :). Maybe BibDesk = =20 should start storing character encoding in xattrs? --=20 Adam= |
|
From: Maarten S. <maa...@xs...> - 2005-06-22 22:04:42
|
On 22 Jun 2005, at 3:32, Michael McCracken wrote:
> Hi - I saw Maarten's posting on the macosx-tex list and the website
> he's set up - nice job!
\begin{blush}
Well, eh, thanks!
\end{blush}
> We should probably add BibDesk to the list of participating projects,
> as soon as I hear what exactly that means.
At the moment I have no idea where we'll end up with the project. The
main idea is that developers of the various tools join forces, to
make sure that common code is implemented using the same (debugged)
code. More importantly perhaps: to develop a common user interface
terminology, to increase consistency between the various tools.
The main aim is communication and collaboration. And to encourage new
developers to contribute to existing tools, rather than starting new
projects - the situation with the equation editors is a prime example
of what we'd like to avoid. Of course when an idea for a radically
new tools comes up, a new project can be started.
Participation of a project means that some developers of that project
will listen to the mailing list, and occationally post commentary,
requests for help, etc. Articles on specific issues are appreciated
(how to add TeX specific AppleScript support, an overview of the code
in your project, so that it becomes easier for others to reuse,
please surprise me).
To spread the word about this project, I'd like to steal some
advertising space in your documentation, the about box or your web-
page - under the assumption that developers embarking on a new
project will do some research, and come across existing tools, which
will lead them to either your project or the umbrella toolbox
project. How these links will work out eventually, I don't know yet,
and I'm not planning on playing a cop on the issue: add a reference
to your own web-location in the about box, and add the toolbox logo
(after the contest for a good logo is finished) to your own web-page.
> You've got my permission to use the BibDesk icon graphic on the
> bibdesk.sf.net site for the
> participating projects page.
I would like to have your description as well: just a short
description to add to the list (what is BibDesk, why should you use
it, and what development tasks could use some extra hands).
> Let me know what else is involved, and thanks for the work
> organizing this.
At the moment: not much: I lack the time right now. I'll add new
articles as I receive them, and the mailing list will go forward.
I'll probably add some of my own scripts to the file download section
or at least to the CVS repository. Private advice on how to maintain
a sourceforge project is appreciated.
Maarten
|
|
From: Will R. <wi...@gu...> - 2005-06-22 13:36:51
|
Hello, I apologise greatly in bringing this up, but I honestly think that [Mactextoolbox-talk] as a prefix to every message sent on this list borders on parody. Any chance of shortening it to something more useable? How about [MTT] or [MTToolbox] or [MTTbox] or even [MacTeXToolbox]...if not, no worries! Sorry for the noise, Will |
|
From: Michael M. <mic...@gm...> - 2005-06-22 01:32:15
|
Hi - I saw Maarten's posting on the macosx-tex list and the website he's set up - nice job! We should probably add BibDesk to the list of participating projects, as soon as I hear what exactly that means. I'm already on this list, and I've cc'd the bibdesk developer list on this email to see if anyone else there wants to join up. You've got my permission to use the BibDesk icon graphic on the bibdesk.sf.net site for the participating projects page. Let me know what else is involved, and thanks for the work organizing this. -mike --=20 Michael McCracken UCSD CSE PhD Student San Diego Supercomputer Center http://www.cse.ucsd.edu/~mmccrack/ |
