Mail Archives: geda-user/2016/09/01/05:54:52
--2:SAEWJIARXUFCJSLPFEIN:nhgwp
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
True, one of the reasons I forked back then was to change the default com=
pilation setup, including opengl. Pcb-rnd has gone a long way since - it&=
#39;s not a collection of random small changes, but has major improvements =
(about 1/3 of all code lines seen some change). Some related to opengl =
long term: as Erich mentioned, the code is much more modular now. For exa=
mple we can compile multiple GUI HIDs, static or dynamic linked, and choo=
se which one to use run-time. Thus there's no need to decide for one =
or the other compile-time, thus the default setting we chose doesn't =
"exclude" other settings. With the conf rewrite, which GUI to use o=
n startup is just configuration setting. (We also have a much better buil=
d system that dynamically enables/disables options depending on what libs=
are found on the system - we don't risk configuration failures if op=
engl deps are not found.) In other words, we could have an opengl as a =
default-on plugin without interfering with my (or anyone's) "gl d=
oesn't work here" policy. That said, I still do not have: - any=
hardware+driver combo that'd run an opengl port at usable frame rate =
- any knowledge or experience with programming opengl - desire to change=
the above two (my time is limited too, and I can spend it better than le=
arning opengl) This means opengl in pcb-rnd happens if someone volunteers=
to do it - or at least do the porting of the GL part. In fact the bigg=
est surprise for me was when I've red that opengl setup (and possibly d=
ri) does not works for You. A few years ago there were problems with that, =
but now it works flawlessly - especially on older hardware. Anyway I will t=
ry dig into Peter's opengl pcb version to check how GL programming is c=
omplicated - completely new territory for me. The easiest path would be t=
o revive the old opengl code in pcb-rnd and then port your plugins: 1. =
The original code has the software render (gdk) and the opengl (gl) code =
both as integral part of the gtk HID. We need to split the the gtk HID in=
to a gtk frame plugin that does the UI (gtk-common: menus, dialog boxes, =
etc) and a drawing engine plugin that would have two implementations (a g=
tk-gdk and a gtk-gl). The drawing engine plugin would depend on gtk-commo=
n. The user-visible plugin would be gtk-gdk and gtk-gl. This needs some s=
cconfig backing (but we already have plugin-plugin dependencies handled p=
roperly in svn HEAD). I can do this part, if somoene does the one in poin=
t 3. It looks like a few hours of effort. 2. Forward porting of the code;=
a lot of big infra has been changed or entierly replaced in pcb-rnd so t=
he gl code most likely doesn't even compile anymore. Since I have all=
this in my head it'd probably take only a few hours for me to fix up=
the gl code to compile again. 3. Once the infra is ready to handle gtk-g=
l again, and once it compiles again, starts the hard work: to make sure i=
t works reasonably. This is what I can't do at all. How much time it&=
#39;d take is somewhat random: it might work out-of-the-box after the abo=
ve 2 points, or it may take days or weeks to get it working. May take som=
e more time to merge post-fork improvements on the gl code from mainline =
to pcb-rnd (I believe there was no trackball at the time of the fork). Th=
is is the part that needs a volunteer. 4. Port your plugins - pcb-rnd i=
s open to have a large collection of plugins constantly maintained togeth=
er with core, avoiding bitrotting. The modular layout and scconfig enable=
s us to do this without having to worry about how many plugins we have. I=
can offer some help and time on this too - having more plugins is always=
a good idea. I will download pcb-rnd and check is I am able to understan=
d UI code and drawing engine. At the same time pcb-opengl drawing is better=
then mainline (in my opinion), so I think it would be better to use it'=
;s code. Still it is a long way for me to, but I will try :-).=C2=A0 Thank =
You Igro2 and Erich for detailed answers. Best Regards, Michael Widlok=0D
--2:SAEWJIARXUFCJSLPFEIN:nhgwp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div><br></div><div class=3D"nh_extra"><blockquote class=3D"nh_quote" style=
=3D"border-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id=3D"=
gwp83ffb26e"><div>True, one of the reasons I forked back then was to change=
the default <br></div><div>compilation setup, including opengl. Pcb-rnd ha=
s gone a long way since - <br></div><div>it's not a collection of random sm=
all changes, but has major improvements <br></div><div>(about 1/3 of all co=
de lines seen some change). Some related to opengl <br></div><div>long term=
: as Erich mentioned, the code is much more modular now.<br></div><div><br>=
</div><div>For example we can compile multiple GUI HIDs, static or dynamic =
linked, <br></div><div>and choose which one to use run-time. Thus there's n=
o need to decide for <br></div><div>one or the other compile-time, thus the=
default setting we chose doesn't <br></div><div>"exclude" other settings. =
With the conf rewrite, which GUI to use on <br></div><div>startup is just c=
onfiguration setting. (We also have a much better build <br></div><div>syst=
em that dynamically enables/disables options depending on what libs <br></d=
iv><div>are found on the system - we don't risk configuration failures if o=
pengl <br></div><div>deps are not found.)<br></div><div><br></div><div>In o=
ther words, we could have an opengl as a default-on plugin without <br></di=
v><div>interfering with my (or anyone's) "gl doesn't work here" policy.<br>=
</div><div><br></div><div>That said, I still do not have:<br></div><div><br=
></div><div>- any hardware+driver combo that'd run an opengl port at usable=
frame rate<br></div><div><br></div><div>- any knowledge or experience with=
programming opengl<br></div><div><br></div><div>- desire to change the abo=
ve two (my time is limited too, and I can spend <br></div><div>it better th=
an learning opengl)<br></div><div><br></div><div>This means opengl in pcb-r=
nd happens if someone volunteers to do it - or <br></div><div>at least do t=
he porting of the GL part.<br></div></div></blockquote></div><div><br></div=
><div>In fact the biggest surprise for me was when I've red that opengl set=
up (and possibly dri) does not works for You. A few years ago there were pr=
oblems with that, but now it works flawlessly - especially on older hardwar=
e. Anyway I will try dig into Peter's opengl pcb version to check how GL pr=
ogramming is complicated - completely new territory for me.<br></div><div><=
br></div><div class=3D"nh_extra"><blockquote class=3D"nh_quote" style=3D"bo=
rder-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id=3D"gwp83f=
fb26e"><div>The easiest path would be to revive the old opengl code in pcb-=
rnd and <br></div><div>then port your plugins:<br></div><div><br></div><div=
>1. The original code has the software render (gdk) and the opengl (gl) <br=
></div><div>code both as integral part of the gtk HID. We need to split the=
the gtk <br></div><div>HID into a gtk frame plugin that does the UI (gtk-c=
ommon: menus, dialog <br></div><div>boxes, etc) and a drawing engine plugin=
that would have two <br></div><div>implementations (a gtk-gdk and a gtk-gl=
). The drawing engine plugin would <br></div><div>depend on gtk-common. The=
user-visible plugin would be gtk-gdk and gtk-gl. <br></div><div>This needs=
some scconfig backing (but we already have plugin-plugin <br></div><div>de=
pendencies handled properly in svn HEAD). I can do this part, if somoene <b=
r></div><div>does the one in point 3. It looks like a few hours of effort.<=
br></div><div><br></div><div>2. Forward porting of the code; a lot of big i=
nfra has been changed or <br></div><div>entierly replaced in pcb-rnd so the=
gl code most likely doesn't even <br></div><div>compile anymore. Since I h=
ave all this in my head it'd probably take only <br></div><div>a few hours =
for me to fix up the gl code to compile again.<br></div><div><br></div><div=
>3. Once the infra is ready to handle gtk-gl again, and once it compiles <b=
r></div><div>again, starts the hard work: to make sure it works reasonably.=
This is <br></div><div>what I can't do at all. How much time it'd take is =
somewhat random: it <br></div><div>might work out-of-the-box after the abov=
e 2 points, or it may take days or <br></div><div>weeks to get it working. =
May take some more time to merge post-fork <br></div><div>improvements on t=
he gl code from mainline to pcb-rnd (I believe there was <br></div><div>no =
trackball at the time of the fork). This is the part that needs a <br></div=
><div>volunteer.<br></div><div><br></div><div>4. Port your plugins - pcb-rn=
d is open to have a large collection of <br></div><div>plugins constantly m=
aintained together with core, avoiding bitrotting. The <br></div><div>modul=
ar layout and scconfig enables us to do this without having to worry <br></=
div><div>about how many plugins we have. I can offer some help and time on =
this <br></div><div>too - having more plugins is always a good idea.<br></d=
iv></div></blockquote></div><div><br></div><div>I will download pcb-rnd and=
check is I am able to understand UI code and drawing engine. At the same t=
ime pcb-opengl drawing is better then mainline (in my opinion), so I think =
it would be better to use it's code. Still it is a long way for me to, but =
I will try :-). Thank You Igro2 and Erich for detailed answers.<br></=
div><div>Best Regards,<br></div><div>Michael Widlok<br></div><div><br></div=
><div><br></div>
--2:SAEWJIARXUFCJSLPFEIN:nhgwp--
- Raw text -