Re: where can I find m4 macro AM_PATH_PYTHON
James Henstridge wrote:
On Wed, 9 May 2001, Lennon Day-Reynolds wrote:
I'm not sure where it *supposed* to come from, but I was able to get a
copy of python.m4 (the Automake macro for Python configuration options)
from the CVS version of Ammonite. I've attached it in case anyone else
is having problems -- drop it in your aclocal directory ('aclocal
--print-ac-dir' for the uncertain).
I'm still having problems with the build on RH7, but am working through
them; on SuSE 7, though, the newest CVS version absolutely refuses to
compile -- something to do with their screwy placement of all the GNOME
core libraries and apps, I think.
Thanks for attaching the macro definition, I found it shows up in the
aclocal.m4 of pygtk package so I just copy and paste it to dia's
acinclude.m4.
I have no idea why you are seeing this problem. The macro is in
acinclude.m4, so should get coppied into aclocal.m4 and get used.
The AM_PATH_PYTHON macro in CVS automake sucks, which is why I made the
modified AM_PATH_PYTHON_JH macro (the changes are being fed upstream),
which says it provides AM_PATH_PYTHON, so the other macros should use it.
I don't know what is causing the problems for you.
From acinclude.m4, I saw AM_PATH_PYTHON_JH is defined, and it uses
AC_PROVIDE([AM_PATH_PYTHON]). I am not very sure what AC_PROVIDE is doing
yet (just from the manual of Autoconf), but I think it is asking for the
AM_PATH_PYTHON macro.
By the way, my autoconf and automake version is up-to-date according to the
README/INSTALL file.
I was able to get the aclocal.m4 generated after attaching the AM_PATH_PYTHON
macro definition at the end of acinclude.m4.
Does the tarball release work okay? (other than the missing
python-startup.py problem :(
I haven't tried the tarball release, but the latest CVS works ok for me
except the missing file problem (therefore no python support in dia for me
yet).
Patrick
questions about diagram and display (diagram.c, diagramdata.c, display.c, etc)
Hi, I was trying to understand how the display, and diagram works but I am confused at this moment. From diagramdata.h, it definds a Rectangle 'extents' and in display, there is a Rectangle called 'visible'. What is extents used for? Because I saw the code in display.c in ddisplay_scroll() function, the new origin is checked against the extents of the diagram. However when I try to output the value of both visible and extents, they are the same. (with 0,10,0,10 for left, right, top, bottom respectively; which is the default setting of the extents). Now, if I am not misunderstanding it, is extents mean the complete drawing area? and visible should be part of the clipped rectangle of extents? If so, then why whould extents and visible are of the same size while I can still scroll the extents with the scroll bar? (btw, I can't scroll the display with keyboard; which is one of the reason why I am looking at ddisplay_scroll()). The next thing is about units. If the printable area (the blue lines of the display window) is *really* the printable area, and if I use UML objects. It could easily occupy a few pages for just one simple UML diagram. It seems the printable area is following the units of measurement of Dia (20 pixel == 1 cm, as it was said in display.h with the default zoom setting). Which means the UML objects are not displayed or drawn according to the zoom factor or units. Please correct me if I am wrong. I just started using it and it seems to have a lot of potentials ;) Regards, Patrick
Re: scrolling on dia, with mouse wheel, scroll tool and keyboard
Cyrille Chepelov wrote: Le dim, mai 20, 2001, à 12:51:48 -0600, Patrick Sung a écrit: The problems is in ddisplay_update_scrollbars() in display.c, an extra area (namely 'extra_border_x' and 'extra_border_y' is added to the entire scrollable (by scroll bar) area (all 4 side). However with key scrolling it won't work because it never take those extra area into account. Since this extra area break a lot of scrolling function of Dia, I would to suggest to take it off for now until we can better define the scrollable area, drawing area, and viewing area (since this could affect a lot of code on display.c and some other files; and may also affect objects in Dia). What is the impact of your change (what was the extra_border_[xy] variables supposed to do) ? When you create a new diagram, the diagram is scrollable. This extra space is created by the extra_border_[xy] variables when the canvas received a GDK_CONFIGURE event (which is triggered once when new diagram is created). Let say if you have a preference setting of 200x200 pixels of initial visible area size, extra_border_[xy] will give an extra 200 pixels to all four sides of the canvas thus making available of 600x600 pixels area *to scroll*. This extra space is reachable only by using the scroll tool or the scroll (not mouse wheel and arrow keys) because the ddisplay_scroll_[direction] functions are called when the mouse wheel and key pressed event is triggered. The ddisplay_scroll_ functions check against the diagram's extent (which is initialized to be smaller 200x200 pixels). Therefore those functions won't scroll the canvas even when you see there are still 200 pixel on each side. None of the objects aware of this extra space created as they are create on the fly when the scrollbar position is being updated (ddisplay_update_scrollbars()). It would look so weird when you can still scroll up using the scroll bar but not using the wheel or arrow keys. ;) hope this clarify the changes. (ps. you can actually assign extra_border_[xy] to zero and see what will happen) Patrick
Re: scrolling on dia, with mouse wheel, scroll tool and keyboard
Cyrille Chepelov wrote: Le dim, mai 20, 2001, à 03:07:50 -0600, Patrick Sung a écrit: hope this clarify the changes. (ps. you can actually assign extra_border_[xy] to zero and see what will happen) Now I see what you mean. With your changes, we get the scrollbar really proportional to the size of the diagram, as would be expected. However, people with small screens will have a problem: now they really have to use the scroll tool to put an object outside of the visible area. I'm a bit tempted by your patch ; until now, I really didn't see the point of using the scroll tool. Having scrollbars consistent with the size of the diagram, and scrollbar behaviour consistent with arrow/wheel scrolling is a Good Thing(tm). OTOH, having the scrollbar scrollable area bigger than the diagram's size can prove itself handy on a small screen. This is why we need some new variables to define such a scrollbar scrollable area. Maybe we can utilize the page layout view like we used to have in a word processor (or Visio) to distinguish between the drawable (and printable) area. Now if a user want to draw outside, they can create a new page. So when you create a new diagram, only one page is displayed (and scrollable if the screen size isn't large enough). This won't destroy the use of the printable area grid line and also gives users a better control of placement of objects in a page. I've committed a one-liner to put extra_border_x = extra_border_y = 0; let's see the reactions. Perhaps it'll be better to let the user choose the behaviour (but I really don't see how to formulate such an option, in a way understandable by users). Thanks Patrick
