From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dl4fX-00048x-GM for qemu-devel@nongnu.org; Wed, 22 Jun 2005 08:49:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dl4fU-00047N-NB for qemu-devel@nongnu.org; Wed, 22 Jun 2005 08:49:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dl4fT-000447-Fx for qemu-devel@nongnu.org; Wed, 22 Jun 2005 08:49:23 -0400 Received: from [128.8.10.164] (helo=po2.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Dl4bL-00066D-2T for qemu-devel@nongnu.org; Wed, 22 Jun 2005 08:45:07 -0400 Date: Wed, 22 Jun 2005 08:41:46 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] quick gtk2.c update Message-ID: <20050622124146.GA25905@jbrown.mylinuxbox.org> References: <214616558.20050621222242@ena.si> <001701c576a6$f12c53f0$334d21d1@organiza3bfb0e> <20050621222420.GA5775@jbrown.mylinuxbox.org> <002601c576b2$e6c825e0$334d21d1@organiza3bfb0e> <20050622035313.GC20093@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050622035313.GC20093@MAIL.13thfloor.at> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Herbert Poetzl Cc: qemu-devel@nongnu.org On Wed, Jun 22, 2005 at 05:53:14AM +0200, Herbert Poetzl wrote: > > It's a very bad idea to have the installer need to go back on to the net to > > download something else. > > > > The user should get the whole thing at once. > I already agreed to this. > yes, that's what hyperlinks are for, just put _another_ one > on the download site saying something like: "this also > requires that you install bla, bla and bla. you can get > a recent version of them here, here and here" ... > Well, the least that could be done would be to have two versions of qemu for download, one that includes the gtk libs and one that doesnt. Along with a big notice in red that says: IF YOU HAVE NO IDEA WHAT GTK IS THEN GET THE VERSION OF QEMU THAT INCLUDES GTK. Or something. > > > GTK libraries are not part of qemu, they are a separate resource that qemu > > > depends on. > > > > As far as the user is concerned, they are part of qemu. > > as is VBRUN.dll for each and every application .. NOT! > > this is the windows concept of 'do not share libraries', > 'do not trust installed resources' and 'do not keep any > compatibility' ... > I agree. This should be avoided, especially because GTK is better well known in the Windows world that qemu is currently. > > Realistically, we don't need GTK. We've already got a GUI with an api. > > That's what windows programmers use. The vast majority of us will never use > > xchat etc. Qemu may be the only one they use. > > so why not make a native GUI for windows, and just > use that? (according to Micro$oft this could not take > longer than a five minutes with their advanced tools) > A) Using microsoft tools may lead to slight incompatibilities with the qemu code which requires gcc. [The -mms-bitfields problem discussed earlier in this thread is a good example of that.] B) Even if they didn't cause any problems (or the GUI was coded by hand), we would still need a separate team of developers for the Win32 GUI. Considering the lack of Windows build maintainers, let alone developers, this would not be a favor to anyone, least of all the end user. C) Sharing the same GTK GUI for Linux qemu and Windows qemu would provide a consistent interface between the two platforms. IMHO this is the most important one. > > And it's not a good idea to distribute the libraries seperately. > > it's neither smart nor good to deploy apps bundled > with a complete operating system. period. > Um... > > Or put them in the Windows system directory. Too much junk gets put there > > already due to years and years of poor programming, careless authors, > > indifferent programmers, and Microsoft's encouragement. > > precisely, and every app wants to use their 'personal' > version of lib whatever, but that's a windows issue, > nothing which should concern QEMU ... > Except it already does. > > best, > Herbert > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.