Op 17 aug 2010, om 10:06 heeft Mike McQuaid het volgende geschreven: > On 13 Aug 2010, at 17:55, Sjors Gielen wrote: > >> A self-contained KDE .app is very hard to make. Not only bundling a Qt >> framework inside the .app makes the .app grow by a few hundred MB, and >> bundling KDE would make the .app grow by a few hundred MB more (this means >> 500-1000 MB for KMail and another 500-1000 MB for Kontact); there's also all >> the technical difficulties of bundling KDE and relocating the KDE daemon >> binaries and running them without conflicts. > > Plenty of applications are shipped with the Qt frameworks. Do you have any > basis for your 1GB figure? Compiled in release mode and unnecessary parts > removed we can get this a lot lower.
The basis is running `du`. Yes, we can get it down a lot, but there are still a lot of resources, sounds, and images that KDE expects to be there, even if applications don't use them. > I like the idea of automatic downloading but not making it look to the user > like that have installed KMail but it hasn't been downloaded yet. I agree that this can be confusing (especially if there are SO many applications that will be shown like that). > Simply, I think part of the problem with Windows and Mac KDE efforts is that > most users (who aren't already KDE users) won't want KDE. They will want > KMail. Or Kate. Or maybe KDEPIM. I very much doubt there are any Mac users > who would honestly want to have every single KDE application installed (and > would use them all) considering the OS comes with replacements for a lot of > them. > > KDE is a desktop environment. OSX already has one. Therefore we should look > at KDE as a collection of applications, in my opinion. That's why I'd like to > see a e.g. Kontact bundle. The fact that we want them to look like a collection of seperate application, does not mean we have to install them like that. Especially if not doing it is much easier, it takes less disk space, and makes it MUCH easier to ship KDE with its daemons along. I don't see any cons to that; my only reason for the .apps was to give the whole a native look and feel. We can have the .app have a script that's executed when uninstalling it (moving it to Trash), so we could let that pop up the uninstaller which uninstalls KDE if the user wants it and the last KDE application was uninstalled. >> [0] It's possible to write our own installer with an interface just like >> that, by using QWizard. Then the KDE.dmg would ship with a KDE.app inside of >> it. What KDE.app does next, is still under discussion. ;-) > > It's possible to write our own installer but there are companies that make > their money doing this, it's really not as simple as you make out. It's > really not a simple problem and our installer will have to be maintained and > look and behave completely differently to how the PackageMaker or .app bundle > installers would. It *is* as simple as I make out, because it uses Fink and MacPorts under the hood, which already do all the work. It is also just as easy for users, since QWizard on Mac looks *exactly* like the .pkg installers and it can be an .app itself - Qt is *very* good at Mac applications. We'd just have to interface with the package manager (that might be harder than it sounds but that's the only thing); the only things it would have to do *itself* are: * Tell the MacPorts / Fink installer to install itself (or write our own installer, but why bother) * Retrieve the status from that installer while it's running * Tell MacPorts / Fink to install package X * Retrieve the status from MacPorts/Fink while it's running * Know what applications map to what packages in both or one of both * Have commandline options for preselecting applications for install or uninstall Package this as an application that looks native and it will make it easy for everyone to use it. >> What's the problem with relying on MacPorts or Fink? They've solved *all* >> the problems with installing the KDE dependencies and KDE itself, on Mac, >> and they have a build system and all packages readily available. Why >> re-invent the wheel when we can re-use the existing ongoing work of the >> MacPorts and Fink volunteers? I know that at least with Fink, binary >> distributions are way easy to create and add and keep up-to-date (uses >> Debian's apt standard for that); you then also get versioning and a >> dependency handler for free. You have stable releases, development releases, >> whatever you want, no extra work required. This is most probably true for >> MacPorts too (I don't know anything about Homebrew). >> >> And of course, users don't need to *know* the installer uses Fink or >> MacPorts below the hood, because they likely won't care, and the installer >> can check if either of both is already installed so there won't be any >> conflicts. > > If we're relying on an external framework to manage our application > installation, if/when it breaks our users will need to know about them. Also, > they both duplicate huge numbers of unnecessary system dependencies, meaning > the packages are bigger than they need to be. Homebrew avoids this but > provides no binary distribution (neither does Macports iirc). No, they don't duplicate huge numbers of unncessary system dependencies. Fink has virtual packages for various things like X servers, it depends on them and tells you what to do if not installed. And if a package is really annoying, we can have a seperate fink-kde addition to Fink for special KDE-dist packages if we want changes that Fink doesn't want. Anything is possible; reinventing the wheel is the wrong solution. (CC'd Fink developers to see what they think.) > I'm still not happy with this and won't work on it, personally. If others are > happy to do so, that's cool. I think I will start on it sometime, after some more public brainstorming. I'll be e-mailing on this list too. > The normal way of keeping OSX applications up to date is Sparkle > http://en.wikipedia.org/wiki/Sparkle_(software) Oh, I didn't know this, but I recognise the dialog. Thanks! Will keep that in mind. > The normal way of dealing with dependencies is to ship them in the > application bundle with the application or to have a PKG that installs the > application. The application bundle should be moveable. This still works. "To have a PKG that installs the application", now it's a .app that behaves exactly like a PKG. It installs KDE in a non-movable location (Fink or MacPorts install dirs), and all application bundles in /Applications or /Applications/KDE are perfectly movable since they only link to that location. I think it's 100% possible to do this transparant and give everybody a complete Mac look-and-feel. > I know your way seems simpler but it also requires writing a lot more > software to integrate with Fink/Macports. It also requires you to pick Fink > or Macports (sounds like Fink because of binary distribution). > > I don't think we're going to agree here but I think the more maintainable > solution would be to do as much as possible with CMake, as much as possible > using CPack or PackageMaker and as much as possible with Sparkle. The other viable solution comes down to writing a dependency resolver yourself. I think if we start with our ideas at this very moment, right now, that I will be done a lot earlier and easier, and I will have the complete KDE building and installing perfectly right from the start. :) (It will also be more maintainable, but it will also have to be maintained more, because relying on an external component has the risk of it being changed.) >> There were a few things you said that made me draw the conclusion, back >> then, that you probably didn't develop on Mac yourself. Especially because >> you were talking about deployable .apps for KDE applications, while that's >> way easier said than done. I've researched it and found many problems with >> the approach. I drew the wrong conclusion, sorry for that. > > No problem. I just mention that because I've shipped Qt applications with > auto-updaters on OSX for both open-source and proprietary applications and > I'm glad I didn't rely on Macports/Fink to do so as the update process is now > maintainable and self-contained. I don't intend to say that interfacing with Mac and FinkPorts is the best way to go for every goal. I really like self-contained .apps, I love the bundle idea Mac has. In this case, however, its cons overweigh the pros for me. You have more experience in this than me, but I'm quite sure that this is the right way to go at this. :) Sjors
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
