Stuart Brorson wrote: > gerbv is built on GTK which is built on XWindows, the unix windowing > system. The GTK port to MS Windows is ragged, and apparently has > problems if you don't write your code in a specific way.
In what way is it ragged? I'm only aware of 1 bug that is affecting us and that is the 'artifacts when printing directly to the printer' one. > The stuff which reads project files makes assumptions about the > underlying file system, which differs between Linux and Windows. That is not the problem. The problem is the stuff which reads init.scm has broken assumptions and it's almost luck that it works on any os currently... Those assumptions are not really OS or FS specific. > Apps which run on both Linux and Windows usualy have lots of > #ifdef/#else clauses to do this on Linux, and that on Windows. We > have only begun to do this work in gerbv. I don't really agree with that. We have very few of those in gerbv and we need very few. In fact, the fewer the better because it makes it more likely that the code will continue to work on both. > You're just stuck in hell because we have lots of Windows > bugs, so lots of menu items don't work as they should. I don't think that is a fair statement at all. I am only aware of 2 bugs in the windows version that don't exist in the unix version. Those are: - loading of project files is broken. I have this fixed in my local tree. This is actually not 100% unique to windows, it is not hard to reproduce in linux. If you ever do this: ./configure --prefix=/tmp/gerbv && make && make install mv /tmp/gerbv /opt/gerbv you'll have the same problem. The only reason this showed up right away under windows is that it is very common to do exactly that under windows and less common on unix-like operating systems. This is something I fixed in PCB long ago so it was pretty easy to bring that code over to gerbv. Note that one way this might show up in unix-land is if you build gerbv, install to a temp area and then just tar that up and put it on a different machine. - printing directly to a printer produces artifacts on circular pads and diagonal traces. I haven't fully investigated but the links that Peter C. gave suggest this is a bug in cairo. As far as I know that is it. In fact, installing gerbv under windows is as easy as the easiest linux and way easier than some, it is just a single installer. In fact it is *way* easier than installing gerbv on a production linux machine I use where I can't freely reinstall updated versions of piles of dependencies. I ended up having to build glib/gtk/cairo/.... all by hand to have a locally up to date version there. There are speed issues on some systems, but there are speed issues under unix-like os's too. It seems to be more related to the exact graphics hardware than the operating system. -Dan _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
