|Subject:||Re: [Gnumed-devel] Some unhandled exceptions, also console output|
|Date:||Tue, 29 Jun 2010 12:54:47 +0200|
|User-agent:||KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.3; i686; ; )|
Am Dienstag 29 Juni 2010, 10:45:43 schrieb Karsten Hilbert:
> > > iii) Xlib: extension "RANDR" missing on display
> > > "/tmp/launch-nf7uqn/org.x:0". ... anything to do?
> > It just tells you that from your X11/video driver/BSD-subsystem RANDR is
> > missing which will prevent you from stuff like resizing or ratating your
> > screen from within X11 (you can still do that from MacOS if you want).
> > This is harmless. However your GNUmed runs on GTK on X11. There is also
> > wxpython which uses the Mac user interface like round buttons and
> > blueish tabs in GNUmed.
> > It has something to do with the options in MacPort. You could check if
> > wxpyhton in MacPorts lets you select options which lead to the Macish
> > user interface instead of the X11 one.
> Before messing/worrying too much with/about this I should
> chip in with the fact that it will not gain much. It won't
> be possible to somehow "activate" the missing
> ResizeAndRotate code in the Mac X server. Simply setting a
> Macish theme won't make GNUmed be Macish either (it may look
> better, though). There's some special code in wxPython to
> make wxPython apps behave more Macish but we are (I am)
> quite some way from worrying about that.
I am not sure I understand what you are saying.
I was referring to this
Mac OS X
However, MacPorts now provides a framework build of Python 2.5 and wxWidgets runs great (and with Aqua!) when using MacPorts. This is not a slight towards Fink, I'm just pointing out that it would be peachy if a note was added that everything works great in MacPorts.
Furthermore, Leopard also provides a framework build of Python 2.5 and that fact is not mentioned.
Here is more relevant info:
I propose a new port "wxWidgets-python" to be the dependency for py*-wxpython with a version number that is in sync with that of the latest stable release of wxPython.
I also add the variant "gtk" for both wxWidgets-python and py26-wxpython. This allows these ports to be built against x11/gtk2 on 64 bit Snow Leopard, avoiding universal builds. This is an effective stop-gap until wx developers release 2.9.x with full Cocoa support.
added gtk variant
add conflict to wxWidgets and flags for i386 carbon
OS X Cocoa build: (soonish) 2.9.1 may also include a build of wxPython based on Cocoa instead of Carbon. If it's not ready by the time of the 2.9.1 release then I expect it soon after.
OS X 64-bit build: (soonish) Once the Cocoa port of wxWidgets and wxPython is in a usable state then I'll look at adding a 64-bit personality to the fat binaries as well.
I am confused. WTF. Aqua, Carbon, Cocoa ? What is next ? Banana ? I assume that snow leopard has a framework build. There is a gtk2 build and another (aqua/carbon/cocoa) build. I would thing that Jim has a GTK2 build right now which is fine. It might look a little different and it may integrate into the Apple menu strucuture. In the Macish build all the GNUmed menu options are integrated into the Mac menu at the top. On Tiger I assume the *other* build is enabled.
Just try if you get the carbon option set or leave it if this is no problem for you.
|[Prev in Thread]||Current Thread||[Next in Thread]|