where does macports store it's installed application database?

[Ryan Schmidt]

On Dec 9, 2009, at 19:07, Panayotis Katsaloulis wrote:

>> You may want to consider whether contributing fixes and new features to Pallet would be more effective than starting a new client from scratch.
> 
> I didn't know this application, and I tried to install it right now. But (hehe) I wasn't able to use it :)
> It crashes (so I probably need to make a new bug report about it).

Regrettably, I noticed that too. There is already a ticket:

http://trac.macports.org/ticket/21259

There is a newer version of Pallet available; the port just needs to be updated to it.


> From the seconds I was able to have a look at it, I am sure there are things that I prefer in my own solution :)

Pallet is certainly not perfect; in fact if I were designing a MacPorts GUI I might do it a totally different way. So I certainly look forward to seeing how you do it!


>> We have a Tcl interface available for potential GUI (or non-GUI) clients to use; Pallet uses it. Using this interface insulates you from changes we may make to MacPorts in the future. If you choose not to use that and try to parse MacPorts receipts, port indexes, and other files directly, your app will probably break in the future as MacPorts revises how it uses those files, which will be more work for you.
> 
> Yes, that's probably a good solution. But in any case I am a bit concerned about speed issues.
> In any case, I totally agree with you !

MacPorts on the command line can take considerable time doing some operations. Some good improvements were made to this recently in MacPorts base (from which all clients of the Tcl API should benefit), and there are undoubtedly still other improvements that could be made. If you can suggest any areas in base that are especially slow and need improvements, please let us know. But if you want to implement your own code in Java and bypass all MacPorts base code, that's of course your choice, and if that ends up leading to a nice fast GUI client for MacPorts I certainly won't complain. :)


>> As a side note, I am curious about your choice to use Java for this client, since MacPorts is primarily used on Mac OS X, whereas Java apps have historically had bad reception on Mac OS X. Certainly I avoid Java apps on the Mac if at all possible, because they typically have worse performance than native Mac OS X Cocoa apps, and their interfaces never seem to quite fit in with the Mac look and feel.
> 
> You are wrong!
> ;)

Well, my opinions are based on years of observations of Java apps on Mac OS classic and Mac OS X. Granted it's a vicious circle: Java apps took huge amounts of memory and were very slow and looked awful in Mac OS classic, therefore I got a bad impression of them, therefore I avoid them, therefore I haven't used many Java apps recently. But the few that I have used recently have not given me any reason to change my opinion.


> I think like everything else, being "compatible" with the look & feel of the underlying system is actually how much effort the programmer wants to use.

Perhaps that's true, but if for example you write an app with Cocoa and Interface Builder, it's extremely difficult to create an interface that doesn't look Mac-like. That is to say, your buttons will look like Mac OS X buttons, your lists will look like Mac OS X lists, and so on. They're standard Mac OS X interface elements. Whereas with Java, things often do not look right. For example in your beta1 jar, the list headers do not look or behave like list headers do in the Finder. The window toolbar, while it bears a superficial visual resemblance to a Mac OS X toolbar, has almost none of the behaviors Mac OS X users are accustomed to. And the text rendering does not respect the LCD font smoothing setting in the Appearance preferences so the text does not look like it does in other applications. This is not a complaint against your app per se, and I understand that your app is not finished and that you'll still improve it; the complaint is that in Java it is even possible (and apparently even the default) to create interface elements that do not look and feel like the rest of the OS. This complaint may extend to other non-Cocoa development environments too, but I have less experience with them (or less knowledge of which apps are made with those environments). But there's a maxim I've heard before which I think is apt, which is something about how those who don't use standard OS widgets are doomed to re-implement them poorly. This goes for web sites that write their own scroll bars using Flash or JavaScript, and to date it seems to apply to Java apps too.


> For example Porticus (which was my only knowledge of macports front-ends) although is written in Cocoa, is as ugly (or pretty) as a KDE application :) .
> I believe that, when you'll manage to see my application, you'll change you idea about Java!

Like most other apps, I don't doubt Porticus could use improvements, but it does have the benefit of at least using standard Mac OS controls and widgets that look and feel like those in other programs.


> Java has a lot of advantages, like for example is a protected language. See for example your situation (the exception you got) and you know exactly what happened.
> In Pallet I got only something like 
> 10/12/2009 2:48:02 π.μ.	com.apple.launchd.peruser.501[274]	([0x0-0xac0ac].org.MacPorts.Pallet[14275]) Job appears to have crashed: Segmentation fault
> What can I do now?  :-)

I would say from a normal user's perspective, there's effectively no difference. The program "didn't work" and the user needed to report the problem to the developer. :-/


> Still, my original idea why to use java is because it's multi-platform and the knowledge I get from working with Java under mac, could be possible to move it under Linux.
> With Obj-C I am tied up to Mac platform, which is something I hate (since I've changed so so many platforms from my day-1 in computers).
> Java has served me rather good for a long time, longer than any other alternative.
> 
> I might agree with you, it's not always the "best choice", but it is a good choice and - at least!!! - it's open source.

I appreciate that Java is useful for projects that need to be cross-platform. I just question whether a MacPorts GUI is such a project. I'm told most of the support for non-BSD systems (such as Linux) was removed in MacPorts 1.8.0, so it might not even compile there now, and anyway few if any of our committers and port maintainers test their ports on non-Mac operating systems, so the bulk of our port collection is unlikely to be of significant value to non-Mac users. The bottom line is MacPorts is made for Mac OS X.

I completely understand wanting to reuse a technology you're already familiar with; I do this too. But before you devote too much time to the endeavor, I want to make sure you're aware of the downsides of using Java for an app on Mac OS X, and that the advantages Java might have in other situations might not apply to this project.


> And finally, if you were really  worried about performance, you wouldn't use tk, right ?
> ;-)

To clarify, MacPorts uses Tcl; there's no Tk anywhere in it that I know of. And sure, it's an interpreted language, which is slower than a compiled language. But plenty of parts of base are written in compiled C to speed it up. Anyway I don't think the interpreted nature of Tcl is ever really to blame for the slow parts of MacPorts; I just think there are inefficiencies in how things have been implemented. This was exemplified for me most clearly recently when MacPorts 1.8.0 was released, where "port outdated" now takes one tenth the time it took under MacPorts 1.7.x, thanks to optimizations by Joshua and Bryan:

http://trac.macports.org/ticket/18259


> Anyway, CafePort (will) use external programs to do the job, so under this context, won't differ much from *C