Hey everyone,
This patch creates a basic infrastructure for printing in monodoc. The
patch is composed of:
* docbrowser.patch - Minor changes to browser.cs / browser.glade to add
printing support
* IPrintManager.cs - Printing interface to allow for different printing
back ends
*
Ok,
this time a description of how I solved it :-)
After checking the dependencies, I noticed that at the beginning of the
configure script an error message appears, while checking for gawk:
D:\Eigene unknown directory.
It was referencing the directory in which I had checked out the code:
Current programming practice is that library exports should have a
common prefix, forming a namespace. Common examples abound in GLib
(with a g_ prefix) and GTK+ (with a gtk_ prefix).
libMonoPosixHelper.so in many cases disregards this, with exports like:
create_z_stream
Hi,
We shouldn't use non-ASCII characters inside code for identifiers but we
can
use other characters in strings and comments. Of course we could use ASCII
but I think UTF-8 is a better solution.
Actually I don't reasonably understand the reason why you can't use
non-ASCII identifier but in
Hello,
I would like to move to utf-8 myself, but we do need a plan to deploy
this, and with all the other changes, my personal preference is to way
after 1.1.9 is released to make the change.
Agreed.
This change is a change that will affect a lot of our contributors, so
we must understand
Hi,
Here is a patch that contains some preprocessor fixes:
- It didn't report expected location (tiny fix).
- When -langversion:ISO-1 is specified, #pragma directive
is always checked, even when it is actually disabled
by #if directive. (Because of this bug,
--- Joe Audette [EMAIL PROTECTED] escreveu:
I was having this problem at r48966 but as of r48977
its building.
Hi Joe!
Sorry for late response.
Nice to know you got it working. :)
I forgot to add the revision number to my message. I will add it next time. I
think putting the revision
I wonder if I could ask for some advice.
I have never really managed to get a completely satisfactory mono
install with all the bits in place and everything working, and in a
condition where it's updateable as well. I currently have mono 1.1.7
installed, but can't get monodevelop to work at
Install MONO from the SUSE 9.3 RPMs. Make sure everything is working before
you upgrade. That includes making sure that mod_mono is working (make sure
Apache 2 is installed), as well as MONODOC and MONODEVELOP. After you are
sure everything is working, then upgrade using Red Carpet (also
Hi,
I have never really managed to get a completely satisfactory mono
install with all the bits in place and everything working, and in a
condition where it's updateable as well. I currently have mono 1.1.7
installed, but can't get monodevelop to work at all, and don't seem to
be able
Paul F. Johnson wrote:
The above sounds like you've installed bits via redcarpet and bits from
source. If you haven't, have you tried running monodevelop from the
command line and see (and report!) the throwback from it? Also, what
errors is redcarpet throwing back?
No. I installed from the
Hi,
The above sounds like you've installed bits via redcarpet and bits from
source. If you haven't, have you tried running monodevelop from the
command line and see (and report!) the throwback from it? Also, what
errors is redcarpet throwing back?
No. I installed from the SuSE disks,
Paul F. Johnson wrote:
From source. I would *always* recommend from source unless the person
does not feel technically up to the task in which case, red carpet has
the most up to date versions (usually)
Please, no Fix the distribution versions and help them package it
correctly (Debian),
13 matches
Mail list logo
