Vadi,
If I am in Mudlet2.1, I can get to the Contents directory, /Application/Mudlet2.1/Contents by selecting /Application/Mudlet2.1 in the finder and then use the context menu to get to the Contents directory. I can't do that in Mudlet 3.0.0.
I'll send you my latest profile from the current directory on that deleteLine() problem.
Mudlet 3.0.0-beta (preview #2)
Re: Mudlet 3.0.0-beta (preview #2)
Yeah, but there's no need to go into the Contents directory. I don't think you can do this with many other applications either what you can do with 2.1.
Re: Mudlet 3.0.0-beta (preview #2)
You can pretty much view the Contents directory of almost all applications on OSX... It's pretty standard
Re: Mudlet 3.0.0-beta (preview #2)
Besides the fact that I don't see a need to view the Contents directory of the application and none has been stated, you still can do it in 3.0:
Re: Mudlet 3.0.0-beta (preview #2)
It's typically only used to patch internal scripts for applications... or kind of inplace upgrade a library or something... The way mudlet is laid out... That is all pretty much done in the mudlet-data folder I believe right?
Re: Mudlet 3.0.0-beta (preview #2)
Not something you should be doing really. mudlet-data stores your profiles, not the application data.
Re: Mudlet 3.0.0-beta (preview #2)
Vadi is right. The mudlet-data directory is in your home folder, which stores your logs/profiles etc. The contents of the app shouldn't be poked around with
Re: Mudlet 3.0.0-beta (preview #2)
The very first time I exported a directory of triggers, mudlet, at that time, defaulted to the contents directory as the place to store it. I run lots of different profiles and reuse scripts, triggers, etc I have made there. I was going there in mudlet 3.0.0 to import some of my previously created Achaea scripts and noticed that I could not get there from inside mudlet 3.0.0, like I done for years from withing mudlets 1.x, 2.x.
Using the Contents directory made sense to me as I had a single point of commonality with all profiles, so I didn't have to hunt through different profiles to find what I needed.
I wasn't trying to raise a morale issue here and don't really need the sermons. If mudlet 3+ is not going to allow that to happen anymore, having made a thoughtful design decision and a break with the past...fine!. That's all the response I needed.
Using the Contents directory made sense to me as I had a single point of commonality with all profiles, so I didn't have to hunt through different profiles to find what I needed.
I wasn't trying to raise a morale issue here and don't really need the sermons. If mudlet 3+ is not going to allow that to happen anymore, having made a thoughtful design decision and a break with the past...fine!. That's all the response I needed.
Re: Mudlet 3.0.0-beta (preview #2)
Slayd, if I am not mistaken, your scripts can access a shared part of mudlet-data (outside the current profile) - I would have to check when I get home but I am fairly certain my scripts use a common area for cross profile libs that have no need to be duplicated on a per profile basis.
Re: Mudlet 3.0.0-beta (preview #2)
Thanks, ktiedt. I will just move the files out of context to somewhere else since 3.0.0 removes the previous utility of that location. You are right. I could use something in that directory area that is not in the profile directory.