 | | Re: pictures at tracker
|
| (I thought I'd replied to this already, maybe I forgot to click Post? Or maybe this will be a duplicate...) (...) Ah, ok. That makes sense. (...) Yes and no. Serving up 500+ images on a single page could be considered counter-productive. I (...) (23 years ago, 15-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) Yes. Even if you had to go back and forth one part at a time, it would be better than having to download the DAT file each time. I hear you about not downloading 500 images but there is a lot to be said for Peeron and the contemplative power (...) (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) I was thinking it could work like Peeron's [ref] links, and pop up another window. Not a great solution, but easier than having to remember to right-click the hyperlink all the time (IMO). (...) I agree. But I think (and I could be wrong) that (...) (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) And thinking about it, I don't really think images for sub-parts & primitives would be super useful - generally these would be certified in conjunction with a part which references them, no? ROSCO (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) Yep, that's the right place to focus. I think Rosco may be right too, subpart images are not as useful. Does that cut the volume down at all usefully, though? (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) Sort of. Primitives should stand alone, and not be considered intimately tied to the file(s) which use them. And it's still useful to see what the subparts look like, especially when the descriptive title is somewhat undescriptive. Steve (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) There are 139 subparts on the tracker now. I'd say that's a fair percentage of the 661 total files. Another place that I think images would be useful is in the "required files" and "related files" lists on the detailed pages. In those lists, (...) (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) The reason I suggested this is not necessarily volume, but ease - if you limit images to top-level parts, all you need to do is when a part is uploaded, go through your dependency list, and re-image all top-level (non sub-) parts that use it. (...) (23 years ago, 16-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) Yeah, but that would be doing the job of make -- reinventing the wheel, so to speak. It should be easier to maintain a dependency file for each unofficial file, and let make figure out what needs to be updated when. Side thought: Kyle (...) (23 years ago, 17-May-02, to lugnet.cad)
| | | | | RE: pictures at tracker
|
| (...) In order for make to process stuff properly, I'll need to tell it the order in which directories shold be searched for dependent files because that information is not in the DAT file itself. We need to build different graphic images (and (...) (23 years ago, 17-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) You listed the order correctly. Unofficial/parts, Unofficial/p, Official/parts, Official/p. (...) For now, let's limit ourselves to discussing graphics images. Some of the distribution files *can't* be built on the server -- I haven't found (...) (23 years ago, 17-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) But we already know exactly when an image needs updating! Using make, you still have to decide when to execute the make command, I'm saying the obvious time to do it is when a file is submitted (update it's image and all those which depend on (...) (23 years ago, 18-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) I have to disagree: we don't 'know' exactly when an image needs updating. We have the information needed to figure out which image(s) need updating, but it's in a form that still needs to be sorted through. Sorting through it isn't too hard, (...) (23 years ago, 18-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) What format are the current dependency files in, and when are they updated? ROSCO (23 years ago, 18-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) They're in a tab-delimited text file, each line contains a super-to-subfile dependency, the status of the subfile - official, unofficial, or not found, and the title of the subfile. Like this: parts/3001.dat p/stud.dat official Stud The code (...) (23 years ago, 18-May-02, to lugnet.cad)
| | | | | RE: pictures at tracker
|
| (...) Steve, I'm kinda busy here this morning, but I'd like to get going on the project soon. For now, I'll do the development offline on my machine, and when I think we're reasonably far along, I'll get acces to the box for testing. Can you send me (...) (23 years ago, 18-May-02, to lugnet.cad)
| | | | | RE: pictures at tracker
|
| All, I have finally figured out what the essential character of the job of generating images for the parts tracker boils down to... Here's how I see it. 1. Official parts live in one actual, real file tree 2. Unofficial parts live in another actual, (...) (23 years ago, 19-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) And when do they get generated? My point being, that's the obvious time to generate any images that depend on the part as well. So how I'd see it working is: 1. Author submits part / subpart / primitive. 2. Your script generates dependencies. (...) (23 years ago, 19-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) I put a zip file containing the ldglite sources with the -MSfilepath patch on the sourceforge at: (URL) I had to tweak one line of code to get it to build with the old version of Mesa used on ldraw.org. It should work for Mesa 4.0 and above (...) (23 years ago, 19-May-02, to lugnet.cad)
| | | | | Re: pictures at tracker
|
| (...) According to Google it seems to be possible: (URL) will check it out. (...) If you can tell which files were deleted, then make _can_ remove them (`zip -doT archive.zip deleted files`). Jacob (23 years ago, 19-May-02, to lugnet.cad)
| |
