Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
2011/4/18 Alberto Ruiz : > So yeah, .RPM/.DEB is absolutely fine for system level components > (platform, shell...). But for applications, I have to say I really > don't agree at all that it is the right mechanism, unless you come up > with a sandboxed approach for apps installed by the user. Apparently what's needed is some kind of per-user package manager. Most things an application will need can be done by manipulating stuff in the home directory. This includes things such as browser plugins. I guess it would be best to ensure that application authors can use every desktop feature without manipulating any root-owned files. Automatically adding ~/bin to PATH if it exists and the .local hierarchy are examples of this approach. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
Hi, On Mon, Apr 18, 2011 at 1:41 PM, Alberto Ruiz wrote: > 2011/4/17 David Zeuthen : >> Honestly, I'm not that interested in solving the "make relocatable app >> providing plug-ins work without installing the app" use-case work >> outside Linux. >> >> FWIW, even on Linux, I'm not even sure it's something worth worry >> about - for the few cases where you need this (such as when installing >> a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just >> using the platform mechanism (e.g. RPM or DEB). > > David, > > I'm afraid it's not just fine for several reasons: Alberto, I don't think you understood what I was saying... what I was saying is that apps should indeed be using something like AppFolders (in a single file or whatever) but plugins etc. should just keep using RPM/DEB/whatever via e.g. PackageKit. The point of my mail was simply answering the "do we need to handle the case where an app ships a plugin" case with a "no". For example, if I'm writing a movie player, then I use alexl's mechanism to produce a single file to distribute the movie player. Specifically, I don't include any plugins in my app because I simply don't need to...the OS has been already setup to make GStreamer get the plugins via e.g. PackageKit or whatever. I also said that if we wanted, we could even handle plugins via something like this https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00090.html which funny enough is a lot like what OS X is doing with their LaunchServices approach (I didn't know that at the time of writing). My point was just that it's not really an interesting corner case. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Mon, Apr 18, 2011 at 1:34 PM, Damjan Jovanovic wrote: > On Mon, Apr 18, 2011 at 7:17 PM, Paul Davis > wrote: >> On Mon, Apr 18, 2011 at 5:03 AM, Alexander Larsson wrote: >> >>> In a specialized setup where you are in control of everything is >>> certainly possible. But in an osx scheme where the user just drops an >>> executable file somewhere it doesn't just work. You'd need something >>> like the the osx launch services to handle it. >> >> all sounds terribly reasonable, with one fatal flaw ... it *is* >> working for us right now, on linux (and various bsd's and solaris and >> ...) >> >> --p > > It "*is*" working only in a very limited way. All package managers > today need root access to install software, which is a security risk > (downloading a DEB from the Internet and double-clicking it allows > arbitrary code execution, as root). Also, eg. students won't have root > access on their school/university PC, making distro packages > completely useless. Installing multiple versions of a package is often > impossible because they're not relocatable. Portable apps for Linux > virtually don't exist. Those are just 4 examples among numerous > others. you're going way beyond what i was responding to alexandre about. the original question was: > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? i wasn't referring to anything involving package managers. portable apps for linux do exist, but i agree that they are rare. we could get into a very long discussion about why that is, but this doesn't seem like the right place for it (even though GTK's handling of run-time located- and loaded- resources is part of the issue for GTK-using apps). i have some strong opinions about it myself, and recently switched my primary project to portable/self-contained status. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
2011/4/17 David Zeuthen : > Honestly, I'm not that interested in solving the "make relocatable app > providing plug-ins work without installing the app" use-case work > outside Linux. > > FWIW, even on Linux, I'm not even sure it's something worth worry > about - for the few cases where you need this (such as when installing > a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just > using the platform mechanism (e.g. RPM or DEB). David, I'm afraid it's not just fine for several reasons: 1. If you want to make your app widely available to different distributions, you need to learn how to create your package for each one of them (and each distro has its own level of difficulty when it comes to create a good package). This makes the "getting your apps to the users" story really BAD for GNOME. You can get an app up and running in Android and OSX in one or two days if it is really simple, hitting the appstores is a matter of barely a week. Getting to the users on Linux can take months. 2. A badly written package can break your package databse in the long run, (there's plenty of stories like this in the context of PPAs in Ubuntu), or mess up with your dependencies in critical ways that the user won't be able to solve. Relying on the system packaging to deploy apps is just broken. Adobe AIR in Ubuntu has broken my system a few times while messing with apps. Creating well formed packages and maintaining them is less obvious thatn you think. 3. You may need your own version of several platform libraries (such as Gtk+). Or ship your own and not having to worry of those being provided by the distro. Again, this story is pretty BAD when you try to do things this way. You may give examples of success in this approach by Google or Dropbox where things are mostly okay. But that's because they do a really good job. I don't want to rely my system integrity on the ability of all application developers to do a really good job on .DEB/.RPM/... packaging. So yeah, .RPM/.DEB is absolutely fine for system level components (platform, shell...). But for applications, I have to say I really don't agree at all that it is the right mechanism, unless you come up with a sandboxed approach for apps installed by the user. -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Mon, Apr 18, 2011 at 7:17 PM, Paul Davis wrote: > On Mon, Apr 18, 2011 at 5:03 AM, Alexander Larsson wrote: > >> In a specialized setup where you are in control of everything is >> certainly possible. But in an osx scheme where the user just drops an >> executable file somewhere it doesn't just work. You'd need something >> like the the osx launch services to handle it. > > all sounds terribly reasonable, with one fatal flaw ... it *is* > working for us right now, on linux (and various bsd's and solaris and > ...) > > --p It "*is*" working only in a very limited way. All package managers today need root access to install software, which is a security risk (downloading a DEB from the Internet and double-clicking it allows arbitrary code execution, as root). Also, eg. students won't have root access on their school/university PC, making distro packages completely useless. Installing multiple versions of a package is often impossible because they're not relocatable. Portable apps for Linux virtually don't exist. Those are just 4 examples among numerous others. Autopackage, Zero Install, Klik, Listaller, Loki Setup, and others exist for a reason. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Mon, Apr 18, 2011 at 5:03 AM, Alexander Larsson wrote: > In a specialized setup where you are in control of everything is > certainly possible. But in an osx scheme where the user just drops an > executable file somewhere it doesn't just work. You'd need something > like the the osx launch services to handle it. all sounds terribly reasonable, with one fatal flaw ... it *is* working for us right now, on linux (and various bsd's and solaris and ...) --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, 2011-04-15 at 14:19 -0400, Paul Davis wrote: > On Fri, Apr 15, 2011 at 1:45 PM, Alexander Larsson wrote: > > > The same thing happens for the other types of files i mentioned above. > > dbus looks only for service files in /usr/share/dbus-1/services, gtk > > looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. > > So, anything that has a file of this type is "hard" to relocate. > > no, GTK can use GTK_PATH for this. > > > Also, apps that consume such files are also hard to relocate. Take > > nautilus for instance, it looks for extensions > > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > > extensions know where to install extensions? > > something like: > > nautilus --extension-directory > > would work just fine, no? > > although the example is not really that similar, this is how we allow > JACK clients to find out where the server can be contacted, via jackd > --tmpdir > > doesn't seem so hard, does it? I'm not saying its impossible to set the environment paths or whatnot to pick up things like this. Its certainly not (although you need to be something of an expert to know what to tweak). However, its hard, because the setting you need to change affects not your app but the environment. Like, if you install an app with a desktop file in a nonstandard prefix, then you need to tell the gnome panel (etc) of this new location, which is much harder than starting your own app with some environment variable set, as this is a global process. In a specialized setup where you are in control of everything is certainly possible. But in an osx scheme where the user just drops an executable file somewhere it doesn't just work. You'd need something like the the osx launch services to handle it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a leather-clad native American messiah plagued by the memory of his family's brutal murder. She's a beautiful mutant former first lady with someone else's memories. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
Hi, On Sun, Apr 17, 2011 at 12:23 AM, Kean Johnston wrote: >> For simplicity, suppose that your all-in-one-files have the extension >> .glick. Suppose also that we have a per-user-per-system daemon >> watching (relevant parts of, such as only ~/Downloads, ~/Desktop and >> ~/Applications) $HOME for such files. That daemon could then make >> resources in each .glick file, such as .desktop files and other >> things, available in the ~/.watcher-daemon hierarchy (by looking into >> each fie). In fact ~/.watcher-daemon could be a FUSE mount the same >> way ~/.gvfs is a FUSE mount. Then you just have to include >> ~/.watcher-daemon in the XDG environment variables and you are >> basically done [1]. > > Now suppose you are not running on UNIX, Honestly, I'm not that interested in solving the "make relocatable app providing plug-ins work without installing the app" use-case work outside Linux. FWIW, even on Linux, I'm not even sure it's something worth worry about - for the few cases where you need this (such as when installing a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just using the platform mechanism (e.g. RPM or DEB). Notably, on both OS X and Windows, that's what you end up doing - for example, on OS X you install a .mpkg file in a system-wide location. And, heck, on Linux we even solved that specific case very nicely using e.g. PackageKit. So it's not really something worth worrying about. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Apr 17, 2011, at 1:33 AM, Damjan Jovanovic wrote: > On Fri, Apr 15, 2011 at 7:45 PM, Alexander Larsson wrote: >> On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: >>> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: >> Of course, some files are inherently made to be external, read by >> other >> applications. Such files are hard to relocate, like application >> icons, >> desktop files, icon themes, widget themes, plugins, custom mimetype >> descriptions, dbus service files. I don't really know what to do >> with these. > > A library can discover its current path by calling dladdr() on *nix > and MacOS X, and GetModulePath() on Windows. The library then loads > resources relative to that path. Yes, thats is doable on many OSes, but its still kinda ugly, as it implies that the relative paths to the files are kept, and thus implies that things are stored in typical unix style hierarchies, etc. It is much cleaner to just have a single file. It doesn't solve the inherently hard things listed above though, because the problem for them is that *other* things than the library itself loads these files. >>> >>> Usually the tool used to solve this problem though is a file system. >>> >>> An appdir like structure is a good compromise between other things >>> needing to easily access the data and having all the stuff in one >>> location that can be easily copied and moved around. >>> >>> Another option might be to simply tar (but not [bg]zip) up the library >>> and related files and change the dynamic linker to mmap the correct >>> subsection of the file instead of the whole thing. >> >> An appdir doesn't solve the issue here. Its not that its hard to load >> the file from the relocated file that makes it problematic. Its the fact >> that the "other" app doesn't even know about the existance of the file. > > Now that I've read up on it, MacOS appdirs do solve that issue, as > follows. Each appdir has a file called info.plist where you list all > your resources. Most/all of the filesystem is monitored for changes by > a service called Launch Services. When it finds a new appdir forming > or changing in the filesystem, it (re)loads its info.plist, and > updates its list of all resources in the system and where each is. > When an application wants to find some resource, it does an RPC to > Launch Services, and gets told where those resources are. > >> For instance, let us take a desktop file as an example. Applications >> typically install their desktop files in /usr/share/applications. That >> way "other" applications like the panel, the open with dialog, etc will >> find it, because they all look in that directory. There are some env >> vars you can set globally to manually make other apps look in a some >> specific other directory, but this is quite limited and doesn't work for >> random relocation of apps. > > The panel keeps track of desktop file unique IDs for desktop files > that are on it and queries Launch Services for the actual location at > launch time. Double-clicking on eg. a PDF file would query Launch > Services for applications that can open the PDF mime type. > >> The same thing happens for the other types of files i mentioned above. >> dbus looks only for service files in /usr/share/dbus-1/services, gtk >> looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. >> So, anything that has a file of this type is "hard" to relocate. > > DBus would query Launch Services for all applications whose info.plist > states they want to launch on session startup. Gtk would query Launch > Services for all appdirs that export a theme. > >> Also, apps that consume such files are also hard to relocate. Take >> nautilus for instance, it looks for extensions >> in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does >> extensions know where to install extensions? > > Nautilus would query Launch Services for... you get the idea :-). > > That link I posted earlier suggested that appdirs can be implemented > backward-compatibly on top of the current Freedesktop standards, by > using inotify/UnionFS/FUSE to union-mount special files anywhere in > the system into the current special locations (eg. union-mount all > .desktop files in the system on /usr/share/applications, all DBus > service files on /usr/share/dbus-1/services, etc.). Well, not quite. LaunchServices handles starting programs and mapping file types to applications. . There is a way to export functionality to other applications called "Services" [1], but it's separate from LaunchServices. Info.plist keys are documented in [2]. None of which has anything to do with either the dynamic linker or loadable modules. Dynamically linked libraries are generally found using an rpath in OSX; that rpath can be set relative to the executable
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, Apr 15, 2011 at 7:45 PM, Alexander Larsson wrote: > On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: >> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: >> > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: >> > >> > >> > > > Of course, some files are inherently made to be external, read by >> > > > other >> > > > applications. Such files are hard to relocate, like application >> > > > icons, >> > > > desktop files, icon themes, widget themes, plugins, custom mimetype >> > > > descriptions, dbus service files. I don't really know what to do >> > > > with these. >> > > >> > > A library can discover its current path by calling dladdr() on *nix >> > > and MacOS X, and GetModulePath() on Windows. The library then loads >> > > resources relative to that path. >> > >> > Yes, thats is doable on many OSes, but its still kinda ugly, as it >> > implies that the relative paths to the files are kept, and thus implies >> > that things are stored in typical unix style hierarchies, etc. It is >> > much cleaner to just have a single file. >> > >> > It doesn't solve the inherently hard things listed above though, because >> > the problem for them is that *other* things than the library itself >> > loads these files. >> >> Usually the tool used to solve this problem though is a file system. >> >> An appdir like structure is a good compromise between other things >> needing to easily access the data and having all the stuff in one >> location that can be easily copied and moved around. >> >> Another option might be to simply tar (but not [bg]zip) up the library >> and related files and change the dynamic linker to mmap the correct >> subsection of the file instead of the whole thing. > > An appdir doesn't solve the issue here. Its not that its hard to load > the file from the relocated file that makes it problematic. Its the fact > that the "other" app doesn't even know about the existance of the file. Now that I've read up on it, MacOS appdirs do solve that issue, as follows. Each appdir has a file called info.plist where you list all your resources. Most/all of the filesystem is monitored for changes by a service called Launch Services. When it finds a new appdir forming or changing in the filesystem, it (re)loads its info.plist, and updates its list of all resources in the system and where each is. When an application wants to find some resource, it does an RPC to Launch Services, and gets told where those resources are. > For instance, let us take a desktop file as an example. Applications > typically install their desktop files in /usr/share/applications. That > way "other" applications like the panel, the open with dialog, etc will > find it, because they all look in that directory. There are some env > vars you can set globally to manually make other apps look in a some > specific other directory, but this is quite limited and doesn't work for > random relocation of apps. The panel keeps track of desktop file unique IDs for desktop files that are on it and queries Launch Services for the actual location at launch time. Double-clicking on eg. a PDF file would query Launch Services for applications that can open the PDF mime type. > The same thing happens for the other types of files i mentioned above. > dbus looks only for service files in /usr/share/dbus-1/services, gtk > looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. > So, anything that has a file of this type is "hard" to relocate. DBus would query Launch Services for all applications whose info.plist states they want to launch on session startup. Gtk would query Launch Services for all appdirs that export a theme. > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? Nautilus would query Launch Services for... you get the idea :-). That link I posted earlier suggested that appdirs can be implemented backward-compatibly on top of the current Freedesktop standards, by using inotify/UnionFS/FUSE to union-mount special files anywhere in the system into the current special locations (eg. union-mount all .desktop files in the system on /usr/share/applications, all DBus service files on /usr/share/dbus-1/services, etc.). > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > al...@redhat.com alexander.lars...@gmail.com > He's a scarfaced pirate werewolf on a search for his missing sister. She's a > ditzy extravagent queen of the dead with an evil twin sister. They fight > crime! > > Damjan Jovanovic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
For simplicity, suppose that your all-in-one-files have the extension .glick. Suppose also that we have a per-user-per-system daemon watching (relevant parts of, such as only ~/Downloads, ~/Desktop and ~/Applications) $HOME for such files. That daemon could then make resources in each .glick file, such as .desktop files and other things, available in the ~/.watcher-daemon hierarchy (by looking into each fie). In fact ~/.watcher-daemon could be a FUSE mount the same way ~/.gvfs is a FUSE mount. Then you just have to include ~/.watcher-daemon in the XDG environment variables and you are basically done [1]. Now suppose you are not running on UNIX, Gtk+ isn't used for the entire environment, you have a user base that distrusts background processes and gets annoyed by them, and gets even more annoyed by random files being created all over the place, and doesn't have FUSE mounts. You have one and only one Gtk+ application that displays a clock. That's it. Do you want multi-megabyte, complicated solutions like this for one app? I know Gtk is very GNOME-centric but it would serve the library best if people always bear in mind that it is deployed outside of a GNOME environment. Some things just don't belong at this level, even though they COULD be implemented here. Just my $0.02. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
I've long had this dream of perfectly relocatable gnome libraries/apps where the executable file itself contained all the information it needs. Relocating something like that is trivial (LD_LIBRARY_PATH is all that is needed). Not even that. Check out the very-often overlooked ELF feature of $ORIGIN :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, Apr 15, 2011 at 7:45 PM, Alexander Larsson wrote: > On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: >> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: >> > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: >> > >> > >> > > > Of course, some files are inherently made to be external, read by >> > > > other >> > > > applications. Such files are hard to relocate, like application >> > > > icons, >> > > > desktop files, icon themes, widget themes, plugins, custom mimetype >> > > > descriptions, dbus service files. I don't really know what to do >> > > > with these. >> > > >> > > A library can discover its current path by calling dladdr() on *nix >> > > and MacOS X, and GetModulePath() on Windows. The library then loads >> > > resources relative to that path. >> > >> > Yes, thats is doable on many OSes, but its still kinda ugly, as it >> > implies that the relative paths to the files are kept, and thus implies >> > that things are stored in typical unix style hierarchies, etc. It is >> > much cleaner to just have a single file. >> > >> > It doesn't solve the inherently hard things listed above though, because >> > the problem for them is that *other* things than the library itself >> > loads these files. >> >> Usually the tool used to solve this problem though is a file system. >> >> An appdir like structure is a good compromise between other things >> needing to easily access the data and having all the stuff in one >> location that can be easily copied and moved around. >> >> Another option might be to simply tar (but not [bg]zip) up the library >> and related files and change the dynamic linker to mmap the correct >> subsection of the file instead of the whole thing. > > An appdir doesn't solve the issue here. Its not that its hard to load > the file from the relocated file that makes it problematic. Its the fact > that the "other" app doesn't even know about the existance of the file. > > For instance, let us take a desktop file as an example. Applications > typically install their desktop files in /usr/share/applications. That > way "other" applications like the panel, the open with dialog, etc will > find it, because they all look in that directory. There are some env > vars you can set globally to manually make other apps look in a some > specific other directory, but this is quite limited and doesn't work for > random relocation of apps. I am not sure whether you want to (1) special-case every "application" on the system no matter where it is or if its path changes, or (2) track "applications" once they've been associated with the desktop somehow (eg. dragged into the panel). The panel could remembering the inode, so even if the name changes, we can still find it (presumably through some novel kernel API that lets us get the path of an inode :-). If the move is across filesystem boundaries then we're out of luck. > The same thing happens for the other types of files i mentioned above. > dbus looks only for service files in /usr/share/dbus-1/services, gtk > looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. > So, anything that has a file of this type is "hard" to relocate. > > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? These are good examples and excellent questions. Have a look at http://replay.waybackmachine.org/20060722121208/http://plan99.net/autopackage/Thoughts_about_AppFolders for an interesting comparison of MacOS's and Linux's approaches. > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > al...@redhat.com alexander.lars...@gmail.com > He's a scarfaced pirate werewolf on a search for his missing sister. She's a > ditzy extravagent queen of the dead with an evil twin sister. They fight > crime! > > Damjan Jovanovic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Apr 15, 2011, at 10:45 AM, Alexander Larsson wrote: > On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: >> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: >>> On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: >>> >>> > Of course, some files are inherently made to be external, read by > other > applications. Such files are hard to relocate, like application > icons, > desktop files, icon themes, widget themes, plugins, custom mimetype > descriptions, dbus service files. I don't really know what to do > with these. A library can discover its current path by calling dladdr() on *nix and MacOS X, and GetModulePath() on Windows. The library then loads resources relative to that path. >>> >>> Yes, thats is doable on many OSes, but its still kinda ugly, as it >>> implies that the relative paths to the files are kept, and thus implies >>> that things are stored in typical unix style hierarchies, etc. It is >>> much cleaner to just have a single file. >>> >>> It doesn't solve the inherently hard things listed above though, because >>> the problem for them is that *other* things than the library itself >>> loads these files. >> >> Usually the tool used to solve this problem though is a file system. >> >> An appdir like structure is a good compromise between other things >> needing to easily access the data and having all the stuff in one >> location that can be easily copied and moved around. >> >> Another option might be to simply tar (but not [bg]zip) up the library >> and related files and change the dynamic linker to mmap the correct >> subsection of the file instead of the whole thing. > > An appdir doesn't solve the issue here. Its not that its hard to load > the file from the relocated file that makes it problematic. Its the fact > that the "other" app doesn't even know about the existance of the file. > > For instance, let us take a desktop file as an example. Applications > typically install their desktop files in /usr/share/applications. That > way "other" applications like the panel, the open with dialog, etc will > find it, because they all look in that directory. There are some env > vars you can set globally to manually make other apps look in a some > specific other directory, but this is quite limited and doesn't work for > random relocation of apps. > > The same thing happens for the other types of files i mentioned above. > dbus looks only for service files in /usr/share/dbus-1/services, gtk > looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. > So, anything that has a file of this type is "hard" to relocate. > > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? At some point some system-level facility has to provide a way of registering such locations. M$Win and MacOSX provide both well known places and a facility for programs to let the system and other apps know where things are if the user put something somewhere else. Linux does too, it just that it's a bit clumsy: Environment variables. The problem for Glib isn't creating such a thing for Gnome (assuming Gnome doesn't already have one), but providing a uniform interface that all GLib-based applications and libraries can use to find their resources regardless of which platform they're running on. Gtk simply needs to use that interface. At the app level, it's up to app developers to use the interface (and to select dependencies that do, too) if they want good portability. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, Apr 15, 2011 at 1:45 PM, Alexander Larsson wrote: > The same thing happens for the other types of files i mentioned above. > dbus looks only for service files in /usr/share/dbus-1/services, gtk > looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. > So, anything that has a file of this type is "hard" to relocate. no, GTK can use GTK_PATH for this. > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? something like: nautilus --extension-directory would work just fine, no? although the example is not really that similar, this is how we allow JACK clients to find out where the server can be contacted, via jackd --tmpdir doesn't seem so hard, does it? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
At 15.04.2011 12:02, Alexander Larsson wrote: On Sun, 2011-04-10 at 12:46 +0200, Hans Breuer wrote: The first thing that should change is making g_malloc and friends use the HeapAlloc function, and ensure that g_mem_is_system_malloc() always returns false. This is really easy to do and shouldn't upset the apple-cart too much. This would break a lot more code than currently is broken. But you can already do this by using g_mem_set_vtable() in your application. Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc. Not really if there are libraries with CRT dependencies involved. Hmm, I'm confused here, in two ways. First of all, what makes switching g_malloc to HeapAlloc useful? Since g_malloc must always be paired with g_free which is from the same dll, there can never be any multiple-crt issues? Exactly, the CRT mixing issues are elsewhere, as I tried to outline in "Getting rid of CRT use in GLib?" http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00052.html I can see how making g_mem_is_system_malloc return FALSE makes sense though, as the definition of "system" here is problematic (multiple such versions exists). I'm pretty sure g_mem_is_system_malloc isn't that heavily used anyway (found 3 uses outside glib in my full gnome checkout), so this would probably not be a problem. Secondly, Hans, how can such a change break apps? With current GLib the actual use of malloc/free or any other allocation pair is under control of the application developer by g_mem_set_vtable(). Not calling g_mem_set_vtable() at all currently 'guarantees' that CRT malloc/free is in use. Using HeapAlloc/HeapFree and always returning FALSE from g_mem_is_system_malloc() would indeed disclose allocation pair mismatches. But some of them could be intentionally and relying on the guarantees above. This is a valid setup, so any code that is broken by this is already "broken" since it matches g_malloc/free and malloc/free without checking g_mem_is_system_malloc. Admitted, I'm considering to fix the one occurence I introduced in Dia becuase of cairo_image_surface_create_for_data(), see: http://git.gnome.org/browse/dia/tree/plug-ins/cairo/diacairo-renderer.c#n799 Any such problems should be fixed and freed. For the mismatch in allocation/deallocation I agree the app is faulty. But still it currently could work (or even does) for the reasons given above. And I consider changing the default allocation is breakin the ABI. Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
Hi, On Fri, Apr 15, 2011 at 1:45 PM, Alexander Larsson wrote: > Also, apps that consume such files are also hard to relocate. Take > nautilus for instance, it looks for extensions > in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does > extensions know where to install extensions? For simplicity, suppose that your all-in-one-files have the extension .glick. Suppose also that we have a per-user-per-system daemon watching (relevant parts of, such as only ~/Downloads, ~/Desktop and ~/Applications) $HOME for such files. That daemon could then make resources in each .glick file, such as .desktop files and other things, available in the ~/.watcher-daemon hierarchy (by looking into each fie). In fact ~/.watcher-daemon could be a FUSE mount the same way ~/.gvfs is a FUSE mount. Then you just have to include ~/.watcher-daemon in the XDG environment variables and you are basically done [1]. Hand-waving, David [1] : Not entirely done, of course - you might have to translate absolute paths on the fly etc etc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote: > On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: > > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: > > > > > > > > Of course, some files are inherently made to be external, read by > > > > other > > > > applications. Such files are hard to relocate, like application > > > > icons, > > > > desktop files, icon themes, widget themes, plugins, custom mimetype > > > > descriptions, dbus service files. I don't really know what to do > > > > with these. > > > > > > A library can discover its current path by calling dladdr() on *nix > > > and MacOS X, and GetModulePath() on Windows. The library then loads > > > resources relative to that path. > > > > Yes, thats is doable on many OSes, but its still kinda ugly, as it > > implies that the relative paths to the files are kept, and thus implies > > that things are stored in typical unix style hierarchies, etc. It is > > much cleaner to just have a single file. > > > > It doesn't solve the inherently hard things listed above though, because > > the problem for them is that *other* things than the library itself > > loads these files. > > Usually the tool used to solve this problem though is a file system. > > An appdir like structure is a good compromise between other things > needing to easily access the data and having all the stuff in one > location that can be easily copied and moved around. > > Another option might be to simply tar (but not [bg]zip) up the library > and related files and change the dynamic linker to mmap the correct > subsection of the file instead of the whole thing. An appdir doesn't solve the issue here. Its not that its hard to load the file from the relocated file that makes it problematic. Its the fact that the "other" app doesn't even know about the existance of the file. For instance, let us take a desktop file as an example. Applications typically install their desktop files in /usr/share/applications. That way "other" applications like the panel, the open with dialog, etc will find it, because they all look in that directory. There are some env vars you can set globally to manually make other apps look in a some specific other directory, but this is quite limited and doesn't work for random relocation of apps. The same thing happens for the other types of files i mentioned above. dbus looks only for service files in /usr/share/dbus-1/services, gtk looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc. So, anything that has a file of this type is "hard" to relocate. Also, apps that consume such files are also hard to relocate. Take nautilus for instance, it looks for extensions in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does extensions know where to install extensions? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced pirate werewolf on a search for his missing sister. She's a ditzy extravagent queen of the dead with an evil twin sister. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote: > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: > > > > > Of course, some files are inherently made to be external, read by > > > other > > > applications. Such files are hard to relocate, like application > > > icons, > > > desktop files, icon themes, widget themes, plugins, custom mimetype > > > descriptions, dbus service files. I don't really know what to do > > > with these. > > > > A library can discover its current path by calling dladdr() on *nix > > and MacOS X, and GetModulePath() on Windows. The library then loads > > resources relative to that path. > > Yes, thats is doable on many OSes, but its still kinda ugly, as it > implies that the relative paths to the files are kept, and thus implies > that things are stored in typical unix style hierarchies, etc. It is > much cleaner to just have a single file. > > It doesn't solve the inherently hard things listed above though, because > the problem for them is that *other* things than the library itself > loads these files. Usually the tool used to solve this problem though is a file system. An appdir like structure is a good compromise between other things needing to easily access the data and having all the stuff in one location that can be easily copied and moved around. Another option might be to simply tar (but not [bg]zip) up the library and related files and change the dynamic linker to mmap the correct subsection of the file instead of the whole thing. Kevin > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Apr 15, 2011, at 6:01 AM, Alexander Larsson wrote: > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: > > >>> Of course, some files are inherently made to be external, read by >>> other >>> applications. Such files are hard to relocate, like application >>> icons, >>> desktop files, icon themes, widget themes, plugins, custom mimetype >>> descriptions, dbus service files. I don't really know what to do >>> with these. >> >> A library can discover its current path by calling dladdr() on *nix >> and MacOS X, and GetModulePath() on Windows. The library then loads >> resources relative to that path. > > Yes, thats is doable on many OSes, but its still kinda ugly, as it > implies that the relative paths to the files are kept, and thus implies > that things are stored in typical unix style hierarchies, etc. It is > much cleaner to just have a single file. > > It doesn't solve the inherently hard things listed above though, because > the problem for them is that *other* things than the library itself > loads these files. ISTM that it's cleaner and more broadly applicable to use something like binreloc (sadly no longer being developed, but widely copied and used in unix applications), where the paths to various resources can be configured at runtime in whatever way is appropriate for the system. We do this with Gnucash and it works well, though some of our dependencies don't and we have to resort to hacks to work around their limitations. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote: > > Of course, some files are inherently made to be external, read by > > other > > applications. Such files are hard to relocate, like application > > icons, > > desktop files, icon themes, widget themes, plugins, custom mimetype > > descriptions, dbus service files. I don't really know what to do > > with these. > > A library can discover its current path by calling dladdr() on *nix > and MacOS X, and GetModulePath() on Windows. The library then loads > resources relative to that path. Yes, thats is doable on many OSes, but its still kinda ugly, as it implies that the relative paths to the files are kept, and thus implies that things are stored in typical unix style hierarchies, etc. It is much cleaner to just have a single file. It doesn't solve the inherently hard things listed above though, because the problem for them is that *other* things than the library itself loads these files. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a scarfaced flyboy cowboy who must take medication to keep him sane. She's a manipulative thirtysomething single mother from out of town. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Fri, Apr 15, 2011 at 11:06 AM, Alexander Larsson wrote: > On Wed, 2011-04-06 at 23:34 +0200, Kean Johnston wrote: > >> Last, but by no means least, is the reliance on "compiled" files, like >> compiled schemas (or in the case of Gtk, icon caches). On UNIX systems >> where things are installed in a universally-accessible location, this isn't >> a problem, but on Win32, where multiple applications could all include >> their own private copies of the DLL's, this is a problem. Fixing this is a >> bit tricky but very doable. Windows does provide two places that are >> predictable and universally accessible: the registry, and %ProgramData%. >> The registry is a poor choice except perhaps for location files inside >> %ProgramData%. The registry is slow, and also imposes some severe >> limitations on key sizes etc. This can be very easily addressed by >> compiling Glib with LIBDIR set to something like "%ProgramData%\Glib\2.x" >> and ensuring that functions like g_file_get_contents() or g_open() all call >> ExpandEnvironmentStrings() on Win32. This is also a relatively small change >> and doesn't change any existing API's (although on Win32 it will have a >> behaviour change). > > Things like this is a problem on unix too, as it makes relocatable > apps/libs hard. > > I've long had this dream of perfectly relocatable gnome libraries/apps > where the executable file itself contained all the information it needs. > Relocating something like that is trivial (LD_LIBRARY_PATH is all that > is needed). > > The plan I have is to add a resource system to gio, similar to > http://doc.qt.nokia.com/4.0/resources.html where you describe the > resources in a file, and during the build this gets compiled and linked > into a read-only section in the library/executable. Then we'd have an > API that allows easy lookup of named resources (in a combined namespace > for all libraries in the app) such that you can easily get inputstreams > to the data or direct pointers to the data. > > This allows all kinds of nice extras, like transparent compressed > resources (although these will not allow direct pointers) and > locale-specific versions of resource files. It will also ensure that all > users on the system map the same resource data instead of loading it in > each process. > > Another aspect is translations. I've been thinking a bit about ways to > relocate these. We could internalize a copy of gettext into glib and > modify it to be able to read mo files directly from the binary. Of > course, this would make the library kind of large, but not larger than > the current total package size. It would be harder to strip out unused > translations in an installation though, but I have some ideas that can > solve this. > > Introspection data could also be made part of the shared library itself, > rather than a separate file. It would just be a custom elf section. > > Of course, some files are inherently made to be external, read by other > applications. Such files are hard to relocate, like application icons, > desktop files, icon themes, widget themes, plugins, custom mimetype > descriptions, dbus service files. I don't really know what to do with > these. A library can discover its current path by calling dladdr() on *nix and MacOS X, and GetModulePath() on Windows. The library then loads resources relative to that path. Damjan Jovanovic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Sun, 2011-04-10 at 12:46 +0200, Hans Breuer wrote: > > The first thing that should change is making g_malloc and > > friends use the HeapAlloc function, and ensure that > > g_mem_is_system_malloc() always returns false. This is really easy to do > > and shouldn't upset the apple-cart too much. > > > This would break a lot more code than currently is broken. But you can > already do this by using g_mem_set_vtable() in your application. > > > Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc. > Not really if there are libraries with CRT dependencies involved. Hmm, I'm confused here, in two ways. First of all, what makes switching g_malloc to HeapAlloc useful? Since g_malloc must always be paired with g_free which is from the same dll, there can never be any multiple-crt issues? I can see how making g_mem_is_system_malloc return FALSE makes sense though, as the definition of "system" here is problematic (multiple such versions exists). I'm pretty sure g_mem_is_system_malloc isn't that heavily used anyway (found 3 uses outside glib in my full gnome checkout), so this would probably not be a problem. Secondly, Hans, how can such a change break apps? This is a valid setup, so any code that is broken by this is already "broken" since it matches g_malloc/free and malloc/free without checking g_mem_is_system_malloc. Any such problems should be fixed and freed. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed misogynist matador from the 'hood. She's a strong-willed cat-loving journalist who don't take no shit from nobody. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Resource framework, relocatability (was Re: Glib: a Win32 discussion)
On Wed, 2011-04-06 at 23:34 +0200, Kean Johnston wrote: > Last, but by no means least, is the reliance on "compiled" files, like > compiled schemas (or in the case of Gtk, icon caches). On UNIX systems > where things are installed in a universally-accessible location, this isn't > a problem, but on Win32, where multiple applications could all include > their own private copies of the DLL's, this is a problem. Fixing this is a > bit tricky but very doable. Windows does provide two places that are > predictable and universally accessible: the registry, and %ProgramData%. > The registry is a poor choice except perhaps for location files inside > %ProgramData%. The registry is slow, and also imposes some severe > limitations on key sizes etc. This can be very easily addressed by > compiling Glib with LIBDIR set to something like "%ProgramData%\Glib\2.x" > and ensuring that functions like g_file_get_contents() or g_open() all call > ExpandEnvironmentStrings() on Win32. This is also a relatively small change > and doesn't change any existing API's (although on Win32 it will have a > behaviour change). Things like this is a problem on unix too, as it makes relocatable apps/libs hard. I've long had this dream of perfectly relocatable gnome libraries/apps where the executable file itself contained all the information it needs. Relocating something like that is trivial (LD_LIBRARY_PATH is all that is needed). The plan I have is to add a resource system to gio, similar to http://doc.qt.nokia.com/4.0/resources.html where you describe the resources in a file, and during the build this gets compiled and linked into a read-only section in the library/executable. Then we'd have an API that allows easy lookup of named resources (in a combined namespace for all libraries in the app) such that you can easily get inputstreams to the data or direct pointers to the data. This allows all kinds of nice extras, like transparent compressed resources (although these will not allow direct pointers) and locale-specific versions of resource files. It will also ensure that all users on the system map the same resource data instead of loading it in each process. Another aspect is translations. I've been thinking a bit about ways to relocate these. We could internalize a copy of gettext into glib and modify it to be able to read mo files directly from the binary. Of course, this would make the library kind of large, but not larger than the current total package size. It would be harder to strip out unused translations in an installation though, but I have some ideas that can solve this. Introspection data could also be made part of the shared library itself, rather than a separate file. It would just be a custom elf section. Of course, some files are inherently made to be external, read by other applications. Such files are hard to relocate, like application icons, desktop files, icon themes, widget themes, plugins, custom mimetype descriptions, dbus service files. I don't really know what to do with these. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a short-sighted amnesiac cop with a secret. She's a cynical kleptomaniac lawyer in the witness protection program. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Sun, 2011-04-10 at 08:12 +0200, Kean Johnston wrote: > On 4/7/2011 4:29 PM, Colin Walters wrote: > > If your application deals with uids, I think you're going to end up > > with platform-specific code; the complexities around identity are just > > too high. That goes doubly for inode numbers, which - why would you > > care unless you're a backup app, and then you're *definitely* going to > > get into platform specific stuff. > In the context of stat, I disagree. Let's suppose you were making a > new-fangled version of tar. Forget for the moment that the specification > for tar may impose limitations on how many bits wide uid/gid's are. You > want your code to be as minimally system-dependent as possible, so you use > glib. If glib provides its own GlibStat structure, and the elements in that > structure are sufficiently wide for all current platforms and reasonable > use, this is useful. That program needs to know if two files are the same > so it checks on inode numbers and only includes the body of the file once > in the archive. So far, nothing particularly system dependent there. If you > *DO* need system dependent stuff, *then* you can use struct stat (or > whatever structure you like), with suitable conditionals protecting that > code, but the average code path that uses struct stat to check for minimal > information such as file size, last modification time and occasionally > ownership (frequently just checking to see if uid/gid are 0) having a > platform-independent structure is a big win for portability. glib already has a GlibStat structure, its called GFileInfo, and its properly abstracted and extendable. It also has a platform independent solution to the "are these two files the same" (G_FILE_ATTRIBUTE_ID_FILE). struct stat is very ugly even on unix (with multiple versions depending on defines and suchlike). Its also has many nonstandard extensions on different unixes. Trying to expose a cross platform direct representation of this is double pain, pain for us having to implement it, and pain for users having to continue use a crappy api. We should just get rid of all uses of stat in our higher level code (using proper abstractions in glib). glib (via gio) also has all sort of i/o abstractions replacing all interesting parts of stdio (and if something is missing we should add it). So, ideally all apps and libraries above glib should be using gio for all i/o, and not stdio (or gstdio). However, I don't think we should remove gstdio from glib as it is a very useful way to quickly get unix specific code "ported" to win32. This is a good initial step to get something running. Later the stdio part can be removed as things are cleaned up. If we manage to get all the stack to not use gstdio, then the crt problem (at least wrt stdio/fds) is "solved", as long as you manage to get a glib build that uses msvcrt.dll. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a fast talking alcoholic paranormal investigator on his last day in the job. She's an elegant red-headed former first lady from a different time and place. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Thu, 2011-04-07 at 10:50 -0700, Ben Pfaff wrote: > Colin Walters writes: > > > If your application deals with uids, I think you're going to end up > > with platform-specific code; the complexities around identity are just > > too high. That goes doubly for inode numbers, which - why would you > > care unless you're a backup app, and then you're *definitely* going to > > get into platform specific stuff. > > One occasional use of inode (and device) numbers is to test > whether two files, that may have different names, are the same. > (Maybe GIO provides a portable way to find that out. In a quick > look I could not find one.) The portable way to do this is to get the G_FILE_ATTRIBUTE_ID_FILE attribute. On unix this has a device:inode format. It looks to me like this has no special implementation on win32, and we should probably add one. Although I have no idea what the right approach is. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a one-legged playboy vagrant with a secret. She's a green-fingered out-of-work Hell's Angel from beyond the grave. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Sun, Apr 10, 2011 at 2:12 AM, Kean Johnston wrote: > On 4/7/2011 4:29 PM, Colin Walters wrote: >> >> If your application deals with uids, I think you're going to end up >> with platform-specific code; the complexities around identity are just >> too high. That goes doubly for inode numbers, which - why would you >> care unless you're a backup app, and then you're *definitely* going to >> get into platform specific stuff. > > In the context of stat, I disagree. Let's suppose you were making a > new-fangled version of tar. Forget for the moment that the specification for > tar may impose limitations on how many bits wide uid/gid's are. You want > your code to be as minimally system-dependent as possible, so you use glib. But is anyone really doing this? Even if someone was, I have trouble thinking that it makes sense to invest a lot in GLib's I/O just for it. > If glib provides its own GlibStat structure, and the elements in that > structure are sufficiently wide for all current platforms and reasonable > use, this is useful. Yeah except for a decent tar app, you really want to know about extended attributes say, which is a whole other set of API already wrapped in Gio. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GOption encoding trouble (was Re: Glib: a Win32 discussion)
2011/4/10 Hans Breuer : > Unfortunately none of the patches in bug #522131 fullfilled all the > requirements. And I do no have a good idea to solve it in GLib either. > The same problem was solved application specific to Dia with > https://bugzilla.gnome.org/show_bug.cgi?id=570592 What exactly are the requirements? Making GOption "just work" when it is used on Windows the same way it is on Unix is impossible. Your Dia problem was different from bug #522131, because you apparently don't use GOption. I fixed the "some filenames don't open" bug in Inkscape a long time ago; the whole point is that the fix prevents me from using GOption. > For me the trouble is still the desired scope of GApplication, namely how > much IPC is really necessary. And is it supposed to be platform IPC (like > COM on win32) or GLib specific? If this is possible using some IPC mechanisms already wrapped by GLib, I guess the GLib IPC could be used. Otherwise use named pipes or file mappings (aka shared memory). I'm not sure whether named pipe creation has the same useful semantics as named mutex creation. http://msdn.microsoft.com/en-us/library/aa365150%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/aa366537%28v=vs.85%29.aspx Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
2011/4/10 Tim Evans : > A combination of GetCommandLineW and CommandLineToArgvW can get you the > arguments as wchar_t strings which could then be converted to utf8. Is this > just something that glib needs to provide a convenience function for? > g_win32_get_utf8_argv() maybe? This is not about a convenience function. The real problem is that GOption cannot parse UTF-8 argument lists. It will always consider the argv to be in locale encoding, and the locale encoding cannot accurately represent filenames on Windows. The input encoding for GOption should be switchable at runtime. Once GOption can parse UTF-8, the convenience function to get the Unicode argv on Windows can be written. However, GetCommandLineW / CommandLineToArgvW do not work, because globs are not expanded. You need to use the function __wgetmainargs with glob expansion set to true, the way it is used in glib/gspawn-win32-helper.c. http://msdn.microsoft.com/en-us/library/ff770599.aspx Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib/win32 issues summary (was Re: Glib: a Win32 discussion)
At 07.04.2011 09:29, Kean Johnston wrote: i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues I wanted to do that but they are all pretty inter-related. I guess the discussion on gstdio could be separate. The independent issues I see are: - GApplication and cross-platform IPC (already discussed w/o any inital patch up to [1], for open design questions see e.g. [2]) - GLib file APIs (part of this is probably also an issue for Gtk+/Broadway/win32 [3]) - GLib cross-platform runtime relocation support [4] - Getting rid of CRT use in GLib? Which C runtine is standard on win32? (As I said in the other mails, I seriously doubt removing the CRT dependency is a viable option [5]) But I also think trying to get the whole picture first is the right approach, like you did. Now it may be time to spin off dedicated threads for some of the issues. With a too broad subject, people will continue to throw in random additional bits just deviating from the original discussion, like [6] ;). (c) attach fixes where applicable Before I spend time making changes I want to get "permission" from the people that are ultimately going to be responsible for committing the fixes. I've wasted too many hours of my life in the past working my ass off on a patch set only to have it rejected by the maintainers because it disagreed with some underlying philosophy. Yeah, I know that feeling :) See e.g.: http://www.hans.breuer.org/gtk/rotten-bits.htm Since I am new to this list and don't know you guys that well I figured I would wait for the maintainers to give me a go/no go before I started doing real work. I'm a long time GLib/Gtk+ win32 developer with commit access for about 10 years, but that does not ensure I'm not sometimes producing rotten bits from the very beginning ;-) Unfortunately there is sometimes a chicken/egg problem with contributions. The old saying "Show me the code!" also applies to Gtk+ development. See https://live.gnome.org/NewAccounts for some details. HTH, Hans [1] http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00021.html [2] http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00082.html [3] http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00050.html [4] http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00047.html [5] http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00052.html [6] http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00022.html Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Getting rid of CRT use in GLib? (was Re: Glib: a Win32 discussion)
At 10.04.2011 17:06, Kean Johnston wrote: But the dependency to the CRT is not the problem, if there is only one of them in process. Agreed, but that is becoming almost impossible to guarantee. If we go to any lengths to ensure a binary-compiled Glib is linked against msvcrt.dll, and an average Windows user uses VS2010, they will run into surprises. Even Microsoft's own code is inconsistent. So? For me the only solution for any serious Windows developer is to accept the fact, because no one can control the whole software stack on win32, not even Microsoft. But if one follows some basic rules regarding resource allocation/deallocation - as outlined in my previous mail - everything can still work just fine. Some things are now using VS-specific versions of the CRT while others are using msvcrt.dll. It really is a mess, and it really is possible to eliminate it from glib. The fact that OTHER components, such as zlib or libxml2 may be constructed to use crt is ... frankly ... their issue :) Nope, it is _my_ issue too, as the maintainer of Dia, which is using all three. And so it is again a GLib issue, at least if the shiny new version is made for real world use ;) I am trying to address glib. I'll get around to addressing the same issues in other dependent libraries too but just becuase zlib may rely on the CRT doesn't mean we shouldn't do what we can to make glib NOT do so. Here you have lost me (from the we;)). Good luck in your quest ... Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
But the dependency to the CRT is not the problem, if there is only one of them in process. Agreed, but that is becoming almost impossible to guarantee. If we go to any lengths to ensure a binary-compiled Glib is linked against msvcrt.dll, and an average Windows user uses VS2010, they will run into surprises. Even Microsoft's own code is inconsistent. Some things are now using VS-specific versions of the CRT while others are using msvcrt.dll. It really is a mess, and it really is possible to eliminate it from glib. The fact that OTHER components, such as zlib or libxml2 may be constructed to use crt is ... frankly ... their issue :) I am trying to address glib. I'll get around to addressing the same issues in other dependent libraries too but just becuase zlib may rely on the CRT doesn't mean we shouldn't do what we can to make glib NOT do so. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On 2011-04-07 15:09, Krzysztof Kosiński wrote: 2011/4/6 Kean Johnston: Everyone, WARNING: long, detailed message. If you don't care about Win32, move on. Other annoying Windows issues specific to glib: 1. GOption fails hard for filenames which are in a language different than your Windows. E.g. Chinese or Russian filenames on English Windows. The arguments passed to main() contain "?" in place of the Chinese / Russian characters and that's just not enough information to correctly identify the file. More detail in the bug: https://bugzilla.gnome.org/show_bug.cgi?id=522131 [snip] A combination of GetCommandLineW and CommandLineToArgvW can get you the arguments as wchar_t strings which could then be converted to utf8. Is this just something that glib needs to provide a convenience function for? g_win32_get_utf8_argv() maybe? -- Tim Evans ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GOption encoding trouble (was Re: Glib: a Win32 discussion)
At 07.04.2011 05:09, Krzysztof Kosiński wrote: 2011/4/6 Kean Johnston: Everyone, WARNING: long, detailed message. If you don't care about Win32, move on. Other annoying Windows issues specific to glib: I seriously doubt this win32 specific. It's a question of default encoding of the terminal, the application and last but not least the file system. This is 'solved' on recent Linux by making all these utf8, but at least I remember the time of G_BROKEN_FILENAMES and G_FILENAME_ENCODING ;) 1. GOption fails hard for filenames which are in a language different than your Windows. E.g. Chinese or Russian filenames on English Windows. The arguments passed to main() contain "?" in place of the Chinese / Russian characters and that's just not enough information to correctly identify the file. More detail in the bug: https://bugzilla.gnome.org/show_bug.cgi?id=522131 Unfortunately none of the patches in bug #522131 fullfilled all the requirements. And I do no have a good idea to solve it in GLib either. The same problem was solved application specific to Dia with https://bugzilla.gnome.org/show_bug.cgi?id=570592 2. GApplication. Mentioned in the mail. This functionality is traditionally implemented using named mutexes and shared memory. http://stackoverflow.com/questions/2285110/restrict-application-to-one-instance-per-shell-session-on-windows For me the trouble is still the desired scope of GApplication, namely how much IPC is really necessary. And is it supposed to be platform IPC (like COM on win32) or GLib specific? Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib cross-platform runtime relocation support (was Re: Glib: a Win32 discussion)
At 07.04.2011 02:26, Paul Davis wrote: On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston wrote: Last, but by no means least, is the reliance on "compiled" files, like compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where things are installed in a universally-accessible location, this isn't a problem, but on Win32, where multiple applications could all include their own private copies of the DLL's, this is a problem. Fixing this is a bit the same thing applies to anyone who wants to make a relocatable Unix "bundle". i've demonstrated that this is entirely possible even without any win32-style mechanisms, although it breaks when GSettings has been used by the desktop to specify modules that GTK should load which are not included in the bundle. the new binary-only packages of Ardour3 use the bag of tricks i've come up with to make GTK, Glib, Gdk-Pixbuf and Pango all find files inside the bundle in preference to any outside of it. This set of functionality is supported for Gtk+/win32 from quite the beginning. Of course it uses win32 specific APIs to calculate the pathes at runtime. it doesn't require any changes to glib, or gtk etc, but the app has to do some stuff. see fixup_bundle_environment() (the OS X or linux cases) here: http://subversion.ardour.org/svn/ardour2/branches/3.0/gtk2_ardour/main.cc This code looks similar to what is done in GLib/Pango/Gtk+/Dia ... Maybe it is time to provide a cross-platform GLib API to simplify it? Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Hi Kean et al., At 06.04.2011 23:34, Kean Johnston wrote: Everyone, WARNING: long, detailed message. If you don't care about Win32, move on. I would like to start a discussion on making changes to Glib for improved Win32 support. These changes will eliminate many of the pitfalls that usually accompany that platform, and better live up to the "mission statement" of Glib (which isn't really a mission statement, but instead is an indication to users of what it is trying to achieve - "It works on many UNIX-like platforms, Windows, OS/2 and BeOS". These are just ideas, and I appreciate any and all feedback. Before even discussing the changes I'd like to propose, it is important to discuss the actual problems the changes are trying to solve. Completely agreed, but ... I am not making any changes just for change's sake. First and foremost of those changes is the complete and total avoidance of the C runtime DLL, msvcrt.dll. There are many good reasons for doing this. ... here you are jumping to conclusions already. Indeed it could be a solution to get rid of C runtime (CRT) usage on win32, but for me there are as many good reasons not to do this. And from my experience with Gtk+, Dia and GIMP porting of the last ten years quite some of the problems you want to solve will remain - or just be shifted to another level. First, none of the modern MS compilers allow you to directly target using msvcrt.dll (which is present on all Windows systems) and instead force you to use compiler-specific versions of the C runtime, which you then have the obligation to either install yourself, or ensure are installed. The 'official' C runtime for GLib and even Windows is msvcrt.dll. It gets update with the system nowadays and I agree it very unfortunate that Microsoft recent compilers are not allowing to target it directly. It is possible to craft a set of tools (using a mixture of the driver development kit, platform development kit, Visual Studio and a large number of hacks) that will allow modern MS compilers to target msvcrt.dll, but doing so is extraordinarily complicated and one tiny mis-step along the way causes things to fail in subtle ways. This failing in subtle ways comes in part from questinable assumptions during the API design of involved libraries. And it only will completely vanish if all libraries in an application use the same CRT. An alternative is to use and support only MinGW and MSYS, and this is really tempting, except that using these tools you can NOT avoid dependence on msvcrt.dll. But the dependency to the CRT is not the problem, if there is only one of them in process. There are severe limitations imposed by using it, not least of which is the fact all file descriptors, the heap and other information is local to each DLL. This 'each DLL' is each CRT, isn't it? So no problem if there is only one. Unlike the UNIX world where a shared object uses the same malloc as an application (under almost all circumstances), It can and ususally is, but there is no guarantee. A good API is providing allocation and deallocation functions like, e.g. - GLib: g_malloc and g_free - libxml : xmlMalloc and xmlFree - cairo: cairo_create and cairo_destroy - Gtk+: g_object_new and g_object_unref an object created in one DLL cannot be freed by another, or a file descriptor opened in one cannot be closed in another. Exactly, not using matching allocation/deallocation functions is asking for trouble, but this is not all win32 specific. The only way to ensure this does not happen is to guarantee that every single library you build with uses the exact same CRT, and that it is shared. This is very difficult to achieve. The other way in achieving this is good API design as outlined above. Bad APIs are leaking implementation details like the underlying runtime objects. By avoiding the CRT altogether and using native Windows functions that use handles, and using a memory allocator other than malloc, all of these problems go away. This is only true if there are no other libraries involved, which still have the assumption of e.g. system wide file indices by int. If you want to use ZLib and GLib like: int fd = g_open (filename, O_RDONLY, 0); gzFile zf = gzdopen(fd,"rb"); it will still fail. Glib already makes this possible by providing its own malloc wrappers, but the current Win32 implementation is the same as the UNIX one in that it is just a very thin layer on top of malloc. Yes, both assume the happy day scenario of only having one CRT in process. The first thing that should change is making g_malloc and friends use the HeapAlloc function, and ensure that g_mem_is_system_malloc() always returns false. This is really easy to do and shouldn't upset the apple-cart too much. This would break a lot more code than currently is broken. But you can already do this by using g_mem_set_vtable() in your application. Memory allocation is the easy bit. HeapAlloc maps nicely onto mallo
Re: Glib: a Win32 discussion
On 4/7/2011 4:29 PM, Colin Walters wrote: If your application deals with uids, I think you're going to end up with platform-specific code; the complexities around identity are just too high. That goes doubly for inode numbers, which - why would you care unless you're a backup app, and then you're *definitely* going to get into platform specific stuff. In the context of stat, I disagree. Let's suppose you were making a new-fangled version of tar. Forget for the moment that the specification for tar may impose limitations on how many bits wide uid/gid's are. You want your code to be as minimally system-dependent as possible, so you use glib. If glib provides its own GlibStat structure, and the elements in that structure are sufficiently wide for all current platforms and reasonable use, this is useful. That program needs to know if two files are the same so it checks on inode numbers and only includes the body of the file once in the archive. So far, nothing particularly system dependent there. If you *DO* need system dependent stuff, *then* you can use struct stat (or whatever structure you like), with suitable conditionals protecting that code, but the average code path that uses struct stat to check for minimal information such as file size, last modification time and occasionally ownership (frequently just checking to see if uid/gid are 0) having a platform-independent structure is a big win for portability. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Colin Walters writes: > On Thu, Apr 7, 2011 at 1:50 PM, Ben Pfaff wrote: > >> (Maybe GIO provides a portable way to find that out. In a quick >> look I could not find one.) > > http://developer.gnome.org/gio/stable/GFileInfo.html#G-FILE-ATTRIBUTE-UNIX-INODE:CAPS A portable way to find out whether two files are the same would work everywhere that GIO works. G_FILE_ATTRIBUTE_UNIX_INODE is not portable, because the documentation says: "This attribute is only available for UNIX file systems." -- Ben Pfaff http://benpfaff.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Colin Walters writes: > If your application deals with uids, I think you're going to end up > with platform-specific code; the complexities around identity are just > too high. That goes doubly for inode numbers, which - why would you > care unless you're a backup app, and then you're *definitely* going to > get into platform specific stuff. One occasional use of inode (and device) numbers is to test whether two files, that may have different names, are the same. (Maybe GIO provides a portable way to find that out. In a quick look I could not find one.) -- Ben Pfaff http://benpfaff.org ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Thu, 7 Apr 2011 10:29:39 -0400, Colin Walters wrote: > So you're suggesting making them private to the app? It's not clear > to me because I don't know the semantics of %ProgramData%. %ProgramData% can be most easily described as a mix between /etc and /usr/share - system-wide configuration and any kind of data that doesn't fit in the program directory should go there. Also, ProgramData is local to the machine - it doesn't roam, and normally isn't shared (and unless the installer changes permissions, it isn't writable by normal users). -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
2011/4/7 Krzysztof Kosiński : > 2011/4/6 Kean Johnston : >> Everyone, >> >> WARNING: long, detailed message. If you don't care about Win32, move on. > > Other annoying Windows issues specific to glib: > > > > 3. GSettings using the registry. This means portable apps (in the > sense of apps that you can carry with you on an USB stick: > http://portableapps.com/) cannot use it, because they have to store > the settings somewhere on the USB stick, not in the registry. It > should be possible to use dconf on Windows. GSettings has switchable backends. An app, or a user, can choose between the registry backend or the keyfile backend at runtime. Sam ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Well, GApplication should grow a Win32 backend. I don't quite think that's "rethinking" or "a good bit" .. it's just filling in the missing bits... Yeah I did perhaps over-state it :) But in other good news further examination of glib showed me that it already wraps, or provides if the system one's are deficient, the problematic stdio functions. About the only bit that's missing is wrapping the actual FILE structure so that, on silly platforms like Win32 where we want to avoid the system stdio, we can. If only Microsoft knew what a terrible can of worms they created with their uncharacteristically badly implemented CRT. Instead of dealing with all of these multiple CRT runtimes they could have kept one, always accessible version with versioned symbols. Sigh. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Hi, For the record, except for GApplication, nothing cross-platoform in GLib/GTK+ is using the GIO D-Bus routines (except for the GIO D-Bus routines themselves). I do agree that we should try avoiding using D-Bus except for Linux/Unix backends in the GLib/GTK+ stack itself. Btw, I wrote about GDBus and Win32 a couple of months back, see http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00123.html The take-away here is that D-Bus on Win32 can be made to work just fine. On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston wrote: > One last thing, since it has proven to be a source of considerable > incompatibility, and that's the reliance on D-Bus. I think it should remain > possible to use dbus if you want it, if your application really needs it, > but to have relatively (from my position of ignorance) unrelated things like > gapplication absolutely rely on it is a mistake, as far as I can see. dbus > is really not appropriate for, or required for, many applications that would > otherwise want to use Glib/Gtk. Should my Windows MP3 editor really need > dbus daemons running just because it uses GtkApplication (which in turn uses > gio/glib and thus the dbus coupling)? First of all, should your MP3 editor spawn dbus-daemon.exe _just_ because it is using GtkAppication? Absolutely not. But if your MP3 editor wants to provide an easy to use interface for automation, remote control or whatever... then, yes, D-Bus is an excellent choice. Even on Win32. So is COM, CORBA, Java Remoting etc. or any other technology but these are not really as cross-platform as D-Bus is (or can be) (Besides, dbus-daemon.exe is just one extra process which should be nowhere as big as your gtk+-using application. Neither in file size or memory/resource usage.) > Seems like a good bit of gio could use > some re-thinking and this again is maybe more appropriate for a 3.0 release > where we may be able to get away with slightly more disruptive changes. Well, GApplication should grow a Win32 backend. I don't quite think that's "rethinking" or "a good bit" .. it's just filling in the missing bits... David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Thu, Apr 7, 2011 at 1:50 PM, Ben Pfaff wrote: > (Maybe GIO provides a portable way to find that out. In a quick > look I could not find one.) http://developer.gnome.org/gio/stable/GFileInfo.html#G-FILE-ATTRIBUTE-UNIX-INODE:CAPS ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
I've never used GLib on windows really myself, just commenting from the perspective of GNOME: On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston wrote: > > By avoiding the CRT altogether and using native Windows functions that use > handles, and using a memory allocator other than malloc, all of these > problems go away. This sounds reasonable. > Memory allocation is the easy bit. HeapAlloc maps nicely onto malloc. There > are other bits that are more problematic. The next easiest to solve is > stat(). Gio already makes a token gesture at wrapping stat() but its > wrapping is a bit TOO thin. On the subject of this, along with "gstdio"; we should be pushing people towards Gio's very extensive and nice I/O API rather than reinventing it in GLib. So for the limitations and weirdness of the random I/O wrappers in GLib on different platforms - document and move on. > Wrapping stat can also fix the problem of having the > uid_t / gid_t types differ not only from system to system, but also change > on the SAME system depending on defines. We can force these to always be > 32-bit. Similarly, ino_t. If your application deals with uids, I think you're going to end up with platform-specific code; the complexities around identity are just too high. That goes doubly for inode numbers, which - why would you care unless you're a backup app, and then you're *definitely* going to get into platform specific stuff. > Last, but by no means least, is the reliance on "compiled" files, like > compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where > things are installed in a universally-accessible location, this isn't a > problem, but on Win32, where multiple applications could all include their > own private copies of the DLL's, this is a problem. Fixing this is a bit > tricky but very doable. Windows does provide two places that are predictable > and universally accessible: the registry, and %ProgramData%. So you're suggesting making them private to the app? It's not clear to me because I don't know the semantics of %ProgramData%. I think it would be a good goal to make deploying these things per-app work more easily. > One last thing, since it has proven to be a source of considerable > incompatibility, and that's the reliance on D-Bus. I think it should remain > possible to use dbus if you want it, if your application really needs it, > but to have relatively (from my position of ignorance) unrelated things like > gapplication absolutely rely on it is a mistake, as far as I can see. I only intended DBus to be used on GNOME; yes, GApplication needs a Windows backend. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
Tor Lillqvist just mentionned recently on his blog (http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html) that he was moving on to new things (this is bad news for us if you consider all the high-quality work he did for many years.) So, at the moment, it's unclear who will be in charge next. On 04/07/2011 09:29 AM, Kean Johnston wrote: >> i think that this message was too long and contained too many issues. >> i believe you'll get more traction if you: >> >> (a) divide the issues > I wanted to do that but they are all pretty inter-related. I guess the > discussion on gstdio could be separate. > >> (c) attach fixes where applicable > Before I spend time making changes I want to get "permission" from the > people that are ultimately going to be responsible for committing the > fixes. I've wasted too many hours of my life in the past working my ass > off on a patch set only to have it rejected by the maintainers because > it disagreed with some underlying philosophy. Since I am new to this > list and don't know you guys that well I figured I would wait for the > maintainers to give me a go/no go before I started doing real work. > > Kean > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Emmanuel Thomas-Maurin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues I wanted to do that but they are all pretty inter-related. I guess the discussion on gstdio could be separate. (c) attach fixes where applicable Before I spend time making changes I want to get "permission" from the people that are ultimately going to be responsible for committing the fixes. I've wasted too many hours of my life in the past working my ass off on a patch set only to have it rejected by the maintainers because it disagreed with some underlying philosophy. Since I am new to this list and don't know you guys that well I figured I would wait for the maintainers to give me a go/no go before I started doing real work. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
2011/4/6 Kean Johnston : > Everyone, > > WARNING: long, detailed message. If you don't care about Win32, move on. Other annoying Windows issues specific to glib: 1. GOption fails hard for filenames which are in a language different than your Windows. E.g. Chinese or Russian filenames on English Windows. The arguments passed to main() contain "?" in place of the Chinese / Russian characters and that's just not enough information to correctly identify the file. More detail in the bug: https://bugzilla.gnome.org/show_bug.cgi?id=522131 2. GApplication. Mentioned in the mail. This functionality is traditionally implemented using named mutexes and shared memory. http://stackoverflow.com/questions/2285110/restrict-application-to-one-instance-per-shell-session-on-windows 3. GSettings using the registry. This means portable apps (in the sense of apps that you can carry with you on an USB stick: http://portableapps.com/) cannot use it, because they have to store the settings somewhere on the USB stick, not in the registry. It should be possible to use dconf on Windows. Regards, Krzysztof ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: a Win32 discussion
On Wed, Apr 6, 2011 at 5:34 PM, Kean Johnston wrote: > Last, but by no means least, is the reliance on "compiled" files, like > compiled schemas (or in the case of Gtk, icon caches). On UNIX systems where > things are installed in a universally-accessible location, this isn't a > problem, but on Win32, where multiple applications could all include their > own private copies of the DLL's, this is a problem. Fixing this is a bit the same thing applies to anyone who wants to make a relocatable Unix "bundle". i've demonstrated that this is entirely possible even without any win32-style mechanisms, although it breaks when GSettings has been used by the desktop to specify modules that GTK should load which are not included in the bundle. the new binary-only packages of Ardour3 use the bag of tricks i've come up with to make GTK, Glib, Gdk-Pixbuf and Pango all find files inside the bundle in preference to any outside of it. it doesn't require any changes to glib, or gtk etc, but the app has to do some stuff. see fixup_bundle_environment() (the OS X or linux cases) here: http://subversion.ardour.org/svn/ardour2/branches/3.0/gtk2_ardour/main.cc there is some other stuff in there but a good part has to do with making the bundle self-contained and self-referencing. > Thank you for your time reading this, and I welcome comments and debate. i think that this message was too long and contained too many issues. i believe you'll get more traction if you: (a) divide the issues (b) file bug reports in bugzilla, and briefly mention them here (c) attach fixes where applicable --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
