PCB (and maybe other things in the Geda suite) should not hard-Rdepend on GTK. It should be using a flag, and propose the choice between GTK, batch, and lesstif. In particular, there is actually a bug in PCB that is GTK specific; when compiling PCB manually and configuring without GTK, the bug goes away. I'd prefer having a <<gentoo way>> to compile and emerge PCB without GTK support. This way, it could be possible for example to force PCB being compiled with batch of lesstif through /etc/portage/package.use ; of course, the ebuild should specify explicitely --with-gui=lesstif (in my case). I think many other ebuilds in the Geda suite may be modified the same way. I think in particular about /usr/bin/gschem in sci-electronics/geda-20070526 for example.
Yeah definitey, the broken motif POS is the way to go... :P
Rebuilding pcb with lesstif GUI is not difficult: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 emerge lesstif export EXTRA_ECONF="--with-gui=lesstif" emerge pcb
Stefan: if I consider I want lesstiff, then, your solution may work. If I consider I dont want GTK at all on my box, it wont do, cause deps will introduce GTK anyway (because of hard depend declared in the ebuild). After a try, yes it works to avoid the GTK bog in PCB of actual version (workspace moving too fast when mouse is passing over a side, to click in menus or options. I just get these harmless warnings: dhp@moon_gen_2:~$ pcb Looking for default_font in . Can't open ./default_font for reading Looking for default_font in /usr/bin/../share/pcb Found default_font in /usr/bin/../share/pcb dhp@moon_gen_2:~$ Any way, I really think that for people who do not want GTK (and there are many in the world), the hard dep should be replaced by an optionnal dep, managed by USE flags (and defaulted to GTK with something like lesstif? ( x11-libs/lesstif ) gtk? ( >=x11-libs/gtk+-2.4 ) then a script in pkg_setup detecting that only one have been given, and then customise ./configure options) )
>the hard dep should be replaced by an optionnal dep, Yes, of course. But for me working with GTK GUI of pcb is nearly impossible because of this "jumping" of the display -- and I think there is currently no pcb developer who can fix this GTK bug soon. So I was going to compile pcb from sources myself or to hack an existing ebuild, when I found the above mentioned way. Please excuse the noise. Regards Stefan Salewski
(In reply to comment #4) > But for me working with GTK GUI of pcb is nearly impossible because of this > "jumping" of the display Thus this bug to support lesstif easier ^^ > and I think there is currently no pcb developer who > can fix this GTK bug soon. Wrong. Patch have been writen by a guy from IRC, and sent to maints; if maints include it, it will be fixed for enxt releases; I was told this 6h before opening this bug. If you want, I could look at my IRC logs and find the name if you want to talk to the guy. I dont mind; next time I need pcb, I use it with lesstif, and I wil have fun with floating toolboxes :) (right click on the top of menu to get the menu in a seperate window :D ) > So I was going to compile pcb from sources myself or to hack an existing > ebuild, when I found the above mentioned way. If that bug did not make me wish to compile pcb without GTK, I would not have create _this_ bug.
>Wrong. Patch have been writen by a guy from IRC, and sent to maints; if maints >include it, it will be fixed for enxt releases; I think this is the wrong place to discuss the GTK bug of pcb, but ... I am watching gEDA-user mailing list: The problem is: The most active pcb developer is using lesstif. There are a few other developers which use GTK, but they are not GTK experts. There exits patches for this bug -- a few people test the patches and are not really happy with it. See gEDA-user mailinglist december 2007: http://archives.seul.org/geda/user/Dec-2007/msg00342.html Regards Stefan Salewski
(In reply to comment #2) > Rebuilding pcb with lesstif GUI is not difficult: Lesstif is going to be removed from the tree, this bug is kinda futile. Dunno whether it works with openmotif, but choosing a horrible terrible dead toolkit that makes eyes bleed vs. modern maintained toolkit like gkt+-2 sounds like a totally obvious choice to me. If pcb is broken w/ gtk, then get it fixed.
A patch have been sent to upstream by an IRC mate; I dont know if upstream received it. Why remove lesstif . I am actuall using lesstif, and I love it very much :) The possibility to extract floating menus is really much more handy than those traditional GTK (Windows like) menus. root@moon_gen_2:/tmp/pcb-20070912# ./configure --with-gui=openmotif [...] checking for which gui to use... openmotif configure: error: openmotif is not a valid gui GTK maybe maitained, but lesstif is better work-efficient to me. Choice is not as obvious as you say.
(In reply to comment #8) Lesstif will be removed because out motif stuff is completely broken due to the FUBARed motif-config idea. That's a fact and completely outside the scope of this bug, see Bug 204249 for this. Since this doesn't work with openmotif, which will be the only motif implementation left in Gentoo, I'm closing this as WONTFIX.
(In reply to comment #9) > Since this doesn't work with openmotif, which will be the only motif > implementation left in Gentoo, I'm closing this as WONTFIX. It does work with openmotif. The option is improperly called lesstif (I'm guessing for historical reasons) but the documentation says it also supports openmotif. I tried and it worked. Also development of the motif interface in pcb hasn't stopped, with for example xrender support for motif as a new feature in pcb-20080202. So check the new ebuild, I've added the whole thing and lots more to it. Please file issues, if any, with this significantly overhauled ebuild in new bugs. Jakub, if you're not going to check the docs and try the code (and I understand you can't thoroughly check all bugs), I would appreciate that you please leave the decision to close this kind of bugs to the maintainers. It really is counter-productive as you closing the bug makes it go under our radar. Denis.
Closing as FIXED now. Denis.
Have phun with motif crap...
tk now supported :) I was exited to see this ebuild: [ebuild U ] sci-electronics/pcb-20080202 [20070912] USE="dbus%* gif gtk%* jpeg motif%* png -tk% -xrender%" 4,142 kB very nice :) Yes, adding those options is what I was hoping for :) But, there is the error I waas expecting in the ebuild: use gtk && use motif && elog "Can't build for GTK+ and Motif..." you put elog, instead of eerror (?). >>> Compiling source in /var/tmp/portage/sci-electronics/pcb-20080202/work/pcb-20080202 ... * Can't build for GTK+ and Motif at the same time. Defaulting to GTK+... * econf: updating pcb-20080202/config.guess with /usr/share/gnuconfig/config.guess come with a green dot :) I dont re-open for now, to not hurt Jakub :) I hope you will receive this comment, and make the trivial update in the coming days. If I dont see a new ebuild coming, I will re-open, or create a new bug. I was wondering how you would force choice between those two options, you attemped what sounds reasonable, but failed implementation of the idea :) I think that the "The Xrender option is only available with Motif." should be an ewarn. What is tk usefull for ? apart from this minor issue, yes, I consider this new ebuild as a proper fix for my querry :) Does pcb-20080202.tar.gz fix the GTK issue ? I will have a look at the Changelog.
Benoît-Pierre, I broke my wrist last night so my answers will be short, sorry. (In reply to comment #13) > very nice :) Yes, adding those options is what I was hoping for :) My pleasure. > But, there is the error I waas expecting in the ebuild: > use gtk && use motif && elog "Can't build for GTK+ and Motif..." Upstream doesn't support building for both gtk and motif. > you put elog, instead of eerror (?). There is no error to halt on, so no point using an eerror statement here. At worst an ewarn, but I'd argue about this if I could type better. > come with a green dot :) See above. > I was wondering how you would force choice between those two options, you > attemped what sounds reasonable, but failed implementation of the idea :) Our users tend to complain a bit too easily when ebuilds error out. And Gentoo is about giving you choices but also making sensible decisions. So in case the user is careless enough to not check the USE flags for pcb and has both gtk and motif selected, the ebuild chooses gtk by default instead of erroring out. I hope that you understand that nowadays the clueless user is more likely to want gtk than motif. If you don't, you may want to make an emergency exit from the 80s, run quickly through the 90s, and join us here in the 21st century. > I think that the "The Xrender option is only available with Motif." should be > an ewarn. Maybe. Maybe not. I could be argued, again. > What is tk usefull for ? See bug #41333. > apart from this minor issue, yes, I consider this new ebuild as a proper fix > for my querry :) My pleasure, really. > Does pcb-20080202.tar.gz fix the GTK issue ? No idea. I don't use pcb, and although I tried I could never reproduce this issue. Denis.
Please, make it at least ewarn, so it ciomes out clearly when reading enotices. I dont think anybody is gonna see elog (I still think this should a fatal error, but you obviously do not want want to make this fatal, and I think I guess your arguments: it's gonna break the build or make the application unusable, thus "is not fatal for the system"). I understand your point, and the fact that having a fatal message will ennoy 99% people. But an elog is way not visible enough to me. If I had to read all elogs, I would spend days on this reading. I stick to earns. I had read the Changelog, and, from memory, the GTK issue have been fixzed upstream around 14th jan (or 12th).
