You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(5) |
Apr
(43) |
May
(34) |
Jun
(47) |
Jul
(44) |
Aug
(8) |
Sep
(37) |
Oct
(27) |
Nov
(31) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
(1) |
Mar
(8) |
Apr
(53) |
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: <smi...@ma...> - 2002-12-06 22:50:44
|
Not sure who took over the DNS information. Whoever has the info, please update it and let the list know what the deal is :-P Begin forwarded message: > From: "SourceForge.net Support" <no...@so...> > Date: Thu Dec 5, 2002 3:07:25 PM America/New_York > To: smi...@us... > Subject: SourceForge.net: crucial update required for project DNS > > Greetings, > > As part of the recent (mid-November) SourceForge.net project service > outage, SourceForge.net has completed a transition to a new IP range. > You are receiving this message because you have been identified as > the project administrator for a project that makes use of > SourceForge.net's VHOST services, as documented at: > https://sourceforge.net/docman/display_doc.php?docid=777&group_id=1 > > In order for your VHOST to continue working correctly, you will need > to update the DNS configuration for your VHOSTs to reflect the IP > address change for vhost.sourceforge.net. This change is documented > in the aforementioned Site Documentation. The DNS for your project > VHOSTs must be updated within the next two weeks. If you are not > the maintainer of the DNS configuration for your project, please > forward this announcement to an appropriate individual. > > Once again, in order for your VHOSTs to continue working correctly, > you MUST UPDATE your VHOST configuration no later than 2002-12-19. > > Inquiries regarding this change may be directed to the > SourceForge.net team by submitting a Support Request at: > https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 > > Thank you, > > SourceForge.net Support > |
From: Josh L. <jjl...@ia...> - 2001-11-21 19:52:50
|
Hello, my name is Josh (alias PimpInBlk). I recently downloaded Theme Machine, Graphic Converter, and a bunch of other software in attempt to further my need to pimp out my new iBook. Anyways, I want to develop a theme based on the movie Hackers. The theme will be very similar to Acid Burn's theme (Acid Burn played by Angelina Jolie). This theme requires Document and Modal Window sizes greater than most of the other themes I see out there. Comparatively, it will be one of the most unique themes ever created for the AM. I have seen some unique themes for Kaleidoscope, but none really for AM. I don't like have to install another Extension to get a theme on my iBook as I want to keep the overhead low on this bitchin' machine. Anyway, as a newbie to theme development, I was wondering if anyone could help me with LAYO resources and changing the settings for document and modal windows. Thanks. PimpInBlk |
From: strobe a. <ana...@ma...> - 2001-06-18 08:01:21
|
If you're lucky enough to have Resourcerer 2.4 there is good news and bad news. The bad news is the OS X version doesn't support templates. The good news is it eventually will support templates, and already supports conversion to and from the flat file version of resource files. Ah well |
From: Jim W. <js...@bl...> - 2001-05-03 03:42:31
|
Hi, Sorry about that last message. I checked my archives, and that discussion came up on the Omnigroup macosx dev list, not this one. But its a good cursory read nonetheless.. Jim |
From: steve <er...@co...> - 2001-05-03 02:12:00
|
On 5/2/01 12:03 PM, "Jim Witte" <js...@bl...> wrote: > Wasn't there a big discussion on this thread entitled 'Legality of > MacThemes' or something similar. I can't find it on the SF archives? > What's going on? I think that was in macthemes-general. |
From: Jim W. <js...@bl...> - 2001-05-02 18:03:31
|
Hi, Wasn't there a big discussion on this thread entitled 'Legality of MacThemes' or something similar. I can't find it on the SF archives? What's going on? Jim Witte js...@bl... |
From: strobe a. <ana...@ma...> - 2001-04-15 08:42:32
|
At 11:28 PM -0500 4/14/01, Jim Witte wrote: > Does anyone know how to do dyld patching on X so that it's global, rather >than application specific? This question came up on Omnigroup X-dev >mailing list. work on the patch first dude |-) It's possible. Before the Finder is launched you set DYLD_INSERT_LIBRARIES. Lots of places to define it, that's like 0.0000001% of the difficulty. |
From: Jim W. <js...@bl...> - 2001-04-15 04:28:24
|
Does anyone know how to do dyld patching on X so that it's global, rather than application specific? This question came up on Omnigroup X-dev mailing list. Jim |
From: strobe a. <ana...@ma...> - 2001-04-15 03:39:15
|
At 4:24 PM -0700 4/14/01, Dave & Jen wrote: >If you check out my webpage I listed this as a bug in the Appearance Manager >code...checkout http://homepage.mac.com/dmaclach and poke around. I'm sure >it (and several other X bugs) are mentioned there. Another advantage to patching the Appearance Manager instead of editing theme data is we know the API, it's published. I think we should definitely put all our resources into researching the dynamic link editor and pasting any info we find here. |
From: strobe a. <ana...@ma...> - 2001-04-15 03:39:14
|
> >Ironically though I am now beginning to recognize what a pain Themes are for >people who build applications that use non-standard Apple controls (and >please don't tell me that people shouldn't use non-standard controls...Take >a look at Photoshop for example and tell me that they don't need some custom >controls). It's hard to make things look nice...and there's a lot of money >going into making certain apps look really nice (especially on X). Adobe is notorious for not keeping their code up to spec. Photoshop 5.5 (and probably 6) doesn't even use Navigation Services. They use the (very) old file dialog. You have access to all the control graphics via Appearance Manager. Drop Drawers allows one to use the current 'theme' which means using the Aqua or whatever tab graphic. Most apps made the switch to Appearance Manager controls when Apple switched to Platinum. The few that didn't were mostly using custom MDEF or WDEFs which will have to be rewritten for OS X anyway so they'll probably add AM code now. Anyway if no themes are made available that'll only encourage people not to use Appearance Manager. I think for now we should concentrate on the dynamic link editor and trying to find as much information about it as possible. |
From: Dave & J. <ma...@ma...> - 2001-04-14 23:25:47
|
If you check out my webpage I listed this as a bug in the Appearance Manager code...checkout http://homepage.mac.com/dmaclach and poke around. I'm sure it (and several other X bugs) are mentioned there. Cheers, Dave > These resources are not actually 16bit. If you change the byte that > specifies the bit depth in the resource to 32bit instead of 16 they will > display properly. I'm not sure why they are set as 16bit when the data is > 32bit. I assume that when OS X draws the pxm#s it ignores the bit depth > specified and assumes that they are all 32bit. > |
From: Dave & J. <ma...@ma...> - 2001-04-14 23:25:45
|
Hey all...long time no type. Just to let you know, I was hit with another cease and desist the other day as they assumed that I was distributing Theminator via MacUpdate. Ironically while I was talking to Mr. Vayra I checked the site, and he mentioned that he'd sent them a cease and desist as well..they appear to have removed it. It sounds like Arentfox (Apple's legal dept in Washington DC) was blanketing all Theme creators. I've had many people contact me and tell me that Apple is on very shaky ground legally....how many of these people are lawyers and/or know what they're talking about? Who knows... I've talked to a couple of people at Arentfox and they have told me that "they" (unknown) are working to setting up a way for people to make Apple certified themes. This was supposed to be in place a while ago...I'm not holding out much hope unfortunately. Have you ever heard anything about this Eric? Are you allowed to comment? Unfortunately (or fortunately) I'm now in a position where I'm pretty much bound into not doing any Theminator work by my current employer and it's various agreements with a certain fruit company. It's really unfortunate for a couple of reasons: a) I thought Theminator was pretty cool from a geek point of view. It had a much better design internally than Theme Machine and some cool special features. You should try looking at a Kaleidoscope theme with it (danger Will Robinson...definitely an ALPHA feature). Honestly...I can't remember if I left it enabled in the last build I sent out. b) I'm getting sick of people slashing Theminator because it's "buggy" and doesn't work for them on X release. Sorry kids...0.5 alpha was the last released version as I remember...haven't had time or energy to play with it since then. c) last but definitely not least..I think Themes on the Mac are a lot of fun and that users really enjoy them. Ironically though I am now beginning to recognize what a pain Themes are for people who build applications that use non-standard Apple controls (and please don't tell me that people shouldn't use non-standard controls...Take a look at Photoshop for example and tell me that they don't need some custom controls). It's hard to make things look nice...and there's a lot of money going into making certain apps look really nice (especially on X). Well, I'm beginning to ramble. Just wanted to let people know I've still got my ear to the ground, and if somebody wanted to convince Apple to let Themes continue, I'd certainly be happy to continue to help out with development if I can. Cheers, Dave PS people have asked why I didn't continue with Theme Machine and did Theminator instead...truth be told I wanted to make Theminator fully scriptable, and the design of Theme Machine really precluded that without a total rewrite. Theme Machine and Theminator don't share a single line of code AFAIK. |
From: strobe a. <ana...@ma...> - 2001-04-14 09:47:55
|
> >I actually like this idea. If we patch the library API's 'n such, we can actually create our own standard for how we think themes should be defined. Kinda like Kali did for the earlier OS's, except that that wouldn't be an extension, it would run as part of the OS so no/less performance hit (especially if we made it non-transparent theme for speed), or compatibility issues. >Or am I not reading this right? Well I'm not an expert on the dynamic link editor, but basically a library is comprised of 'modules' which are loaded when needed into memory. By compiling replacement modules in a custom library and setting the DYLD_INSERT_LIBRARIES environment variable path these modules are loaded instead. This is undoubtedly what Keleidascope for OS X (of completed) will do. For added benefit we could probably implement Window Shade too. I just wish there was a decent manual on the dynamic link editor other than the man page. There's probably an old school NeXT book on the subject, I haven't found any examples of this procedure. Apple uses it when you want to debug leaks. It patches the malloc call or something. Read the docks on OS X debugging, it's in there somewhere. They don't provide the source to the patch library, but you have to set the DYLD_INSERT_LIBRARIES path. |
From: Aaron S. <aa...@ge...> - 2001-04-14 05:26:41
|
Is anyone working on a themes patcher/installer so we can distribute aqua derivative themes? This way we can avoid distributing Apple copyrighted material. I may develop one but I'd like to avoid duplicating work. - aaron sittig blackhole coder/designer |
From: Aaron S. <aa...@ge...> - 2001-04-14 05:18:02
|
Any themeing library we could build would probably have to call into the Window Server which at the moment has no public API. Apple's made a little noise about opening this up but I don't really think it's going to happen. If Apple moved all control drawing and layout to a single library, then we could maybe patch it. At this point though, we could just as well edit the theme data files which the library would use. - aaron sittig blackhole coder/designer >> I think the chances that if themes are ever supported again that >> they will use the allegro format are slim. >> >> Anyway without layo what's the point? >> >> Patching OS X libraries via the dynamic link editor may be our only >> recourse. Probably more stable too, these APIs are less likely to >> change than the theme format which looks abandoned and ready for the >> chopping block. > > I actually like this idea. If we patch the library API's 'n such, we > can actually create our own standard for how we think themes should > be defined. Kinda like Kali did for the earlier OS's, except that > that wouldn't be an extension, it would run as part of the OS so > no/less performance hit (especially if we made it non-transparent > theme for speed), or compatibility issues. > Or am I not reading this right? > -SPOOF |
From: SPOOF <SP...@ma...> - 2001-04-14 03:46:21
|
>I think the chances that if themes are ever supported again that >they will use the allegro format are slim. > >Anyway without layo what's the point? > >Patching OS X libraries via the dynamic link editor may be our only >recourse. Probably more stable too, these APIs are less likely to >change than the theme format which looks abandoned and ready for the >chopping block. I actually like this idea. If we patch the library API's 'n such, we can actually create our own standard for how we think themes should be defined. Kinda like Kali did for the earlier OS's, except that that wouldn't be an extension, it would run as part of the OS so no/less performance hit (especially if we made it non-transparent theme for speed), or compatibility issues. Or am I not reading this right? -SPOOF -- .---------------------------------------------------------------------. || From the Desk of: David SPOOF Hemenway E-Mail: SP...@ma... || || -Computer Programmer -Vocalist -Computer Sales Associate || || -Web Designer -Trumpet Player -Computer Consultant || '---------------------------------------------------------------------' |
From: strobe a. <ana...@ma...> - 2001-04-14 03:37:30
|
> >Let me know what you think. Again, if you don't want to say something >publicly you can mail Brian or I and we'll take that into consideration. I'm >going to write a response to Mr. Vayra later on, I'll post a draft of it to >the -general list Friday afternoon PST. I think the chances that if themes are ever supported again that they will use the allegro format are slim. Anyway without layo what's the point? Patching OS X libraries via the dynamic link editor may be our only recourse. Probably more stable too, these APIs are less likely to change than the theme format which looks abandoned and ready for the chopping block. |
From: Jim W. <js...@bl...> - 2001-04-13 19:51:42
|
Hi, Does any particular resource in the MacOS9 system files contain the grid spacing and grid offset parameters? For a *long* time I've wanted to have a way to alter the grid spacing, as I have an enormous number of files on my desktop (35+). I've recently considered writing an extension that would patch the SetFInfo call, and calculate and set the positions myself for files, then figure out some way to force the Finder to update the screen (if needed, maybe call InvalRect), but I'm not sure how much sense that make now that X is out (which could probably use some tweaking of it's own, but it's much harder to patch from what I've read). Thanks, Jim |
From: Aaron S. <aa...@ge...> - 2001-04-13 10:00:40
|
> In light of Apple giving us the cease & desist order for distribution of > Theme Machine we need to look at what we're going to do in the future. How long ago did this happen? Are they referring just to Theme Machine for OS8.5? Reply in private if you wish. - aaron sittig |
From: steve <er...@co...> - 2001-04-13 07:58:02
|
I cross-posted this to make sure I hit the biggest possible audience. This is a big one :). In light of Apple giving us the cease & desist order for distribution of Theme Machine we need to look at what we're going to do in the future. I plan on emailing the lawyer who contacted Brian to see what exactly we need to do to be in compliance. They mentioned removing Theme Machine specifically but I'd rather avoid any complications down the road. Can we still distribute the source code a la LAME, what about the resource documentation, etc. I have a feeling they won't want us to do any of the above. We could simply remove Theme Machine and wait for them to later discover the rest of it; they may not even care. Our only real ammunition in this case is that it would generate a lot of negative publicity in the open-source community (Slashdot, etc.) - this is a much murkier area than someone blatantly ripping off Aqua, IMO. I haven't consulted legal counsel but think it's possible that our use of the leaked beta themes to reverse-engineer the theme format is probably going to end up screwing us over. Keep in mind that most of the work on this was done way back before 8.5 was released and Apple seemed to be planning on releasing their 3 beta themes with it's official release. What I think would be legal would be if we started over and did the same thing with the Aqua theme released with OS X without using any of the old data as the basis for that information. I think it's likely that anyone who worked on this before, including myself, would be precluded from doing it due to their having worked on the original with the leaked themes. I realize this is against Apple's OS X EULA but I don't think that would be held up in court. Their case would certainly be much weaker anyway. There isn't really anyone working on Theme Machine right now. Chris has done some work on making it OS X compatible but nobody has the time to devote to getting it out the door right now. I think the theme documentation is more valuable at this point, that would allow other developers to produce an editor to work on themes. Fortunately for whoever wanted to work on figuring out the theme format, it's quite a bit less complicated in OS X. The primary components of an OS X theme are: 1) pxm# (pixmap) resources 2) plut color/pattern definition tables I'm not even sure that the last one is actually used by Cocoa, that may be hard coded as well (but I think it's used as well). The more complicated resources such as layo, et al aren't used by Cocoa and wouldn't be of much use to anyone constructing a theme. It would still be good to get them all re-done anyway though. If we decide to continue to have a theme editor it might be a good idea to make its support for various elements dependent on something like a set of XML files which define the resource formats which it will edit. That way even *if* the reverse-engineering of Aqua was found to be infringing our editor couldn't be seen as doing so by itself. I'm still going to try to keep our current level of theme support going, but it can't hurt to start work on reverse-engineering Aqua again and think about how an open-source editor can survive any shenanigans from Apple's legal goons :). Let me know what you think. Again, if you don't want to say something publicly you can mail Brian or I and we'll take that into consideration. I'm going to write a response to Mr. Vayra later on, I'll post a draft of it to the -general list Friday afternoon PST. Steve, MTP |
From: <ook...@ma...> - 2001-04-11 05:09:52
|
check it out... http://www.resexcellence.com/themes/ Finally a complete OS X theme that's not an Aqua rework...I'm definitely downloading it to see what kind of workarounds had to be made... |
From: strobe a. <ana...@ma...> - 2001-04-10 12:03:43
|
You know RGBA graphics open a world of opportunities. One could make a realistic looking 'gold' or 'chrome' theme. One could also make a semitransparent theme where tabs and other controls look more liquid than Aqua. Just stirring ideas while I fume about the lack of Cocoa 'layo' support and window shade |
From: strobe a. <ana...@ma...> - 2001-04-07 12:32:08
|
> >There is some possibility that Cocoa and Carbon will eventually share the same theme-drawing code. They use separate code in the first version mostly for historical reasons. I'm surprised Apple still uses pxm#s instead of a PDF. A complete theme package in OS X would require lots of different graphics formats it seems. icns, pxm#, ppat, PDF, what else? |
From: steve <er...@co...> - 2001-04-06 20:28:28
|
On 4/6/01 7:16 AM, "Eric Schlegel" <er...@ap...> wrote: > There is some possibility that Cocoa and Carbon will eventually share > the same theme-drawing code. They use separate code in the first version > mostly for historical reasons. To be honest while I think themes would be a cool feature for OS X to have there are bigger fish to fry at the moment. There are only so many engineers to go around and this probably isn't going to be anybody's priority until things settle down some more. > Most accurately, Mac OS 9.0 and later have support for data fork > resources, and that support is exported via CarbonLib in 1.3 and later > using FSOpen/CreateResourceFile APIs. Cool, thanks :). I saw that 1.3b2 was out, I'll have to grab that tonight and see if I can scare up Aaron's source (or maybe you're already looking into this Aaron?) |
From: steve <er...@co...> - 2001-04-06 19:58:31
|
On 4/6/01 7:08 AM, "SPOOF" <SP...@ma...> wrote: > Have you thought of writing up a quick guideline thing on how to > write for carbon specific code? This might be a boon both to themes, > but also to OS X developers everywhere. We could post it to our site > as part of development for theme people if you wanted to do this, and > explain what it's for. There are better places to get Carbon developer information, but having an open-source application that does CarbonEvents is a good thing. I'm sure I've seen Aaron on the Apple Carbon-Dev list, that's a really good resource for people who want to learn more about it. Strobe writes: > Unfortunately I have zero interest in making a theme which Cocoa apps can use. > I want a theme like NeuTech. My point was that you're going to be spending time using it to make sure it's release quality, it might as well not be horrible to use. For example, just because you *could* redefine the window widget sizes to be smaller than Cocoa expects, you could just as easily mask off the portion you don't want to use. That way you could still do something like move the widgets wherever you want them, but it won't look so bad on the Terminal window. If you want to take the time to do it let me know and I'll send you a copy of the as-yet-unreleased new version of NeuTech, it has most of the window stuff converted to pxm# resources to avoid that bug (though I don't see it anymore, never did on this machine). |