You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(16) |
Apr
(100) |
May
(78) |
Jun
(44) |
Jul
(86) |
Aug
(56) |
Sep
(29) |
Oct
(70) |
Nov
(110) |
Dec
(104) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(189) |
Feb
(77) |
Mar
(90) |
Apr
(101) |
May
(79) |
Jun
(96) |
Jul
(220) |
Aug
(90) |
Sep
(117) |
Oct
(152) |
Nov
(77) |
Dec
(62) |
2006 |
Jan
(71) |
Feb
(149) |
Mar
(144) |
Apr
(156) |
May
(56) |
Jun
(149) |
Jul
(38) |
Aug
(90) |
Sep
(49) |
Oct
(71) |
Nov
(67) |
Dec
(100) |
2007 |
Jan
(76) |
Feb
(52) |
Mar
(73) |
Apr
(96) |
May
(88) |
Jun
(88) |
Jul
(155) |
Aug
(139) |
Sep
(54) |
Oct
(174) |
Nov
(217) |
Dec
(93) |
2008 |
Jan
(125) |
Feb
(161) |
Mar
(69) |
Apr
(54) |
May
(85) |
Jun
(134) |
Jul
(143) |
Aug
(98) |
Sep
(82) |
Oct
(131) |
Nov
(147) |
Dec
(189) |
2009 |
Jan
(61) |
Feb
(71) |
Mar
(86) |
Apr
(51) |
May
(78) |
Jun
(102) |
Jul
(98) |
Aug
(88) |
Sep
(140) |
Oct
(22) |
Nov
(18) |
Dec
(24) |
2010 |
Jan
(11) |
Feb
(43) |
Mar
(23) |
Apr
(39) |
May
(46) |
Jun
(34) |
Jul
(17) |
Aug
(16) |
Sep
(46) |
Oct
(48) |
Nov
(29) |
Dec
(58) |
2011 |
Jan
(35) |
Feb
(83) |
Mar
(41) |
Apr
(33) |
May
(23) |
Jun
(39) |
Jul
(6) |
Aug
(23) |
Sep
(30) |
Oct
(22) |
Nov
(68) |
Dec
(55) |
2012 |
Jan
(43) |
Feb
(40) |
Mar
(28) |
Apr
(9) |
May
(96) |
Jun
(54) |
Jul
(468) |
Aug
(678) |
Sep
(640) |
Oct
(112) |
Nov
(60) |
Dec
(154) |
2013 |
Jan
(113) |
Feb
(50) |
Mar
(74) |
Apr
(17) |
May
(45) |
Jun
(32) |
Jul
(52) |
Aug
(16) |
Sep
(66) |
Oct
(60) |
Nov
(64) |
Dec
(62) |
2014 |
Jan
(43) |
Feb
(25) |
Mar
(29) |
Apr
(9) |
May
(5) |
Jun
(60) |
Jul
(31) |
Aug
(42) |
Sep
(19) |
Oct
(13) |
Nov
(9) |
Dec
(2) |
2015 |
Jan
(45) |
Feb
(29) |
Mar
(8) |
Apr
(2) |
May
(10) |
Jun
(8) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(7) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
(4) |
Apr
(43) |
May
(2) |
Jun
(20) |
Jul
(7) |
Aug
(39) |
Sep
(20) |
Oct
(11) |
Nov
(9) |
Dec
|
2017 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
(1) |
May
(2) |
Jun
(16) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(10) |
Apr
(1) |
May
(16) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
2019 |
Jan
(3) |
Feb
(4) |
Mar
(7) |
Apr
(20) |
May
|
Jun
(10) |
Jul
(15) |
Aug
(19) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
(15) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Adam J. <ada...@gm...> - 2019-07-27 10:23:35
|
Hi Fred, I'm so sorry to hear that. I wish you quick recovery. Regards, Adam sob., 27 lip 2019, 06:39 użytkownik Frank Trampe <fra...@gm...> napisał: > Hi, Fredrick. > > I am very sorry to hear about this. I know how frustrating it is to be > unable to work for any period of time, but there's no issue or pull request > as important as your recovery. For what it's worth, and I feel bad for even > talking business, your work finding and fixing bugs and adding features has > significantly increased our frequency of releases, so it's not a big deal > if something you have in progress does not make the next one. > > I hope that you're back in a good state as quickly as possible and will > keep you in my prayers until that time. > > Best wishes, > > Frank > > > On Fri, Jul 26, 2019 at 10:15 PM Fred Brennan <cop...@ki...> > wrote: > >> I have a PR open, an open change request, and plenty of issues open (as >> always). There are also unmade announcements on Twitter, but since I only >> started making those a week ago I don't think that's a big deal. >> >> Yesterday at ~7:00 a.m. I sustained second degree burns on a third of my >> skin's surface area. I had to undergo a debridement in hospital. >> >> I will continue to work on the project, perhaps even by Monday (UTC+8), >> although perhaps not. >> >> If you can help me close whatever I have open, especially my open PR, I'd >> appreciate that. If you have a question for me that you can't answer on >> your >> own, please e-mail it to me. If you want proof for whatever reason and I >> know >> you somewhat well, you may also ask for that, but I won't be putting that >> on a >> public mailing list. >> >> Thanks >> Fred Brennan (@ctrlcctrlv) >> >> >> >> >> >> _______________________________________________ >> fontforge-devel mailing list >> fon...@li... >> https://lists.sourceforge.net/lists/listinfo/fontforge-devel >> http://fontforge.10959.n7.nabble.com/Developer-f3.html >> > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: Frank T. <fra...@gm...> - 2019-07-27 04:39:22
|
Hi, Fredrick. I am very sorry to hear about this. I know how frustrating it is to be unable to work for any period of time, but there's no issue or pull request as important as your recovery. For what it's worth, and I feel bad for even talking business, your work finding and fixing bugs and adding features has significantly increased our frequency of releases, so it's not a big deal if something you have in progress does not make the next one. I hope that you're back in a good state as quickly as possible and will keep you in my prayers until that time. Best wishes, Frank On Fri, Jul 26, 2019 at 10:15 PM Fred Brennan <cop...@ki...> wrote: > I have a PR open, an open change request, and plenty of issues open (as > always). There are also unmade announcements on Twitter, but since I only > started making those a week ago I don't think that's a big deal. > > Yesterday at ~7:00 a.m. I sustained second degree burns on a third of my > skin's surface area. I had to undergo a debridement in hospital. > > I will continue to work on the project, perhaps even by Monday (UTC+8), > although perhaps not. > > If you can help me close whatever I have open, especially my open PR, I'd > appreciate that. If you have a question for me that you can't answer on > your > own, please e-mail it to me. If you want proof for whatever reason and I > know > you somewhat well, you may also ask for that, but I won't be putting that > on a > public mailing list. > > Thanks > Fred Brennan (@ctrlcctrlv) > > > > > > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: Abraham L. <tis...@gm...> - 2019-07-27 04:33:31
|
Oh my goodness, Fred! That sounds absolutely awful! Hope you have a speedy recovery. If working on this keeps you from resting or otherwise doing something to heal, then stop. It can wait, I’m sure. Thanks for all you’ve done! Best, Abraham On Fri, Jul 26, 2019 at 9:15 PM Fred Brennan <cop...@ki...> wrote: > I have a PR open, an open change request, and plenty of issues open (as > always). There are also unmade announcements on Twitter, but since I only > started making those a week ago I don't think that's a big deal. > > Yesterday at ~7:00 a.m. I sustained second degree burns on a third of my > skin's surface area. I had to undergo a debridement in hospital. > > I will continue to work on the project, perhaps even by Monday (UTC+8), > although perhaps not. > > If you can help me close whatever I have open, especially my open PR, I'd > appreciate that. If you have a question for me that you can't answer on > your > own, please e-mail it to me. If you want proof for whatever reason and I > know > you somewhat well, you may also ask for that, but I won't be putting that > on a > public mailing list. > > Thanks > Fred Brennan (@ctrlcctrlv) > > > > > > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: Fred B. <cop...@ki...> - 2019-07-27 03:14:58
|
I have a PR open, an open change request, and plenty of issues open (as always). There are also unmade announcements on Twitter, but since I only started making those a week ago I don't think that's a big deal. Yesterday at ~7:00 a.m. I sustained second degree burns on a third of my skin's surface area. I had to undergo a debridement in hospital. I will continue to work on the project, perhaps even by Monday (UTC+8), although perhaps not. If you can help me close whatever I have open, especially my open PR, I'd appreciate that. If you have a question for me that you can't answer on your own, please e-mail it to me. If you want proof for whatever reason and I know you somewhat well, you may also ask for that, but I won't be putting that on a public mailing list. Thanks Fred Brennan (@ctrlcctrlv) |
From: T J <jt...@ou...> - 2019-07-15 11:45:43
|
Regarding your questions: 1. gdraw 2. Not really, no. Most of the time it’s just inspecting code to figure out what’s going on. But if you have some understanding of how gui toolkits work, it’s not too bad. The gist of it is: gdraw exposes a public interface, which allows you to: * Create toplevel and child windows * Draw and render text to that window (usually using Pango and Cairo, unless you’ve somehow managed to disable that, in which case it uses straight X/Xlib calls) * Receive events on that window (mouse/keyboard events, expose/render events, resize events etc) There’s then some indirection, because behind that interface may be one of three implementations, an X backend (gxdraw), which works directly with Xlib, a GDK backend (ggdkdraw), which uses GDK to create/manage windows, and a Postscript backend (gpsdraw), which is mostly not functional. >From there, there’s a somewhat functional, mostly broken toolkit of widgets (ggadget/gwidget), which you can use, so you don’t completely have to implement everything from scratch. 1. Painfully. But in brief, you set up some state and desired attributes, then either call GDrawCreateTopWindow (toplevel windows) or GDrawCreateSubWindow (child windows). You then probably use some of the widgets from gwidget/ggadget, which involves setting up a lot more state and some event handlers. 2. When a window is constructed, it passes in an event handler, in the source you’ll often find it called *_e_h, e.g. splash_e_h. This receives information about things like mouse click/key events, expose (paint) events etc. When you use premade widgets, you can sometimes pass in a callback to one of those as well, which just builds on that aforementioned event handler. Jeremy From: Thor Christopher<mailto:tca...@gm...> Sent: Monday, 8 July 2019 10:45 PM To: fon...@li...<mailto:fon...@li...> Subject: [fontforge-devel] Some rookie questions about GUI Hi, this might seem like some very basic stuff here, but I've been skimming through the code just to get an overview on how FontForge is built and some really basic stuff just seems difficult to discern from the code and documentation alone. I think this project could learn a lot from InkScape when it comes to documentation and code structure. Anyway, the first thing I do when I try and understand code is to look for the GUI code so I can see how the UI fits with the functionality of the program. For FontForge this has been rather difficult, all I could find about the GUI from the docs is this part from the FAQ: "Why doesn't it use the native MS Windows or Mac windowing system? · FontForge is not a commercial product and is not bound by the constraints of the market. · Doing that port doesn't interest me. · I don't have time nor do I have the skill to take that task on. · I'd like to encourage people to use Linux/unix Of course, if I were to use either gtk or qt<https://fontforge.github.io/faq.html#widget-set> some of the difficulties of porting would vanish. But unfortunately I don't like either of those widget sets. Now... if you would like to do the port, that would be wonderful. I encourage you to do so. Why is FontForge based on a non-standard widget set? ..." None of this information explains what this widget set is or how it draws its GUI, the only hint I've found is that it uses Cairo, somewhere in the code it looks like it draws the GUI pixel by pixel, and there's a GDraw directory with some datatypes such as GWindow and GWidget that seem to be related to the UI, but trying to follow the function calls and see where it ends it's very difficult to get an idea on how the GUI code works. Since I'm still confused about this, I think this is probably something a lot of other people might have a problem understanding as well when they first start looking into the FontForge source code. I'd say it increases the learning curve and reduces the possibility of more developers contributing to this project. Maybe you should have a more in depth overview on which libraries are used and how they work in the docs? Some of my questions are: 1. What is the name of this non-standard widget set? 2. Is there any documentation for how it works? 3. How is a window created using this widget set? 4. Where do I find the event listeners? Is it a signal/slot pattern, or something else? Hope I'm not spamming with too basic stuff here, but I've been trying to get into the code without any luck several times now, and I'm starting to think this is something other people might want to know about as well. - Thor Arisland |
From: Jose Da S. <di...@jo...> - 2019-07-14 23:20:56
|
On July 8, 2019 05:44:59 AM Thor Christopher wrote: > Hi, this might seem like some very basic stuff here, but I've been > skimming through the code just to get an overview on how FontForge is > built and some really basic stuff just seems difficult to discern from > the code and documentation alone. It is probably understandable to write code and not put much effort into documenting it if you are the sole creator and maintainer. If you look at FontForge (up to 20120731), you have one author, and a few contributors. > I think this project could learn a lot from InkScape when it comes to > documentation and code structure. There are a number of factors at play here: I think there will be a lot more developers interested in SVG graphics than there are developers interested in Fonts, so you should expect a bigger pool of talent looking at InkScape vs FontForge. Lacking a larger pool of eyes looking at & fixing code, as a creator and maintainer, you may likely shy-away from external contributions if you don't think you can comfortably merge and maintain incoming stuff (and lack new eyes to come along and help). Suppose you imagine a drive-by contribution that is given, merged, and then you cannot maintain it. There are a lot of ideas floating in the existing code. There was a time shortly after 20120731 where pretty much anything contributed got merged in, some good, some bad, some so-so. You'll see different coding styles, different opinions on what goes, stays, etc. FontForge was created at a time when 1GB harddrives were considered huge, and fonts were designed with size and speed in mind, now we're reading of some sfd files that run 500M or larger in size, harddrives are more like 2TB in size, solid state drives are becoming common, and RAM is more like 16GB. The past fonts were mainly bitmap, and vector fonts were only beginning to be seen in the past, today, vector fonts are common, and bitmap rarer. More could be said, but it is what it is :-) New help is appreciated. > Anyway, the first thing I do when I try and understand code is to look > for the GUI code so I can see how the UI fits with the functionality of > the program. For FontForge this has been rather difficult, all I could > find about the GUI from the docs is this part from the FAQ: > > * "**Why doesn't it use the native MS Windows or Mac windowing system?* > > - *FontForge is not a commercial product and is not bound by the > constraints of the market.* > - *Doing that port doesn't interest me.* > - *I don't have time nor do I have the skill to take that task on.* > - *I'd like to encourage people to use Linux/unix* > > *Of course, if I were to use either gtk or qt > <https://fontforge.github.io/faq.html#widget-set> some of the > difficulties of porting would vanish. But unfortunately I don't like > either of those widget sets.* > > *Now... if you would like to do the port, that would be wonderful. I > encourage you to do so.* > * Why is FontForge based on a non-standard widget set? ..."* > None of this information explains what this widget set is or how it > draws its GUI, the only hint I've found is that it uses Cairo, > somewhere in the code it looks like it draws the GUI pixel by pixel, > and there's a GDraw directory with some datatypes such as GWindow and > GWidget that seem to be related to the UI, but trying to follow the > function calls and see where it ends it's very difficult to get an idea > on how the GUI code works. Since I'm still confused about this, I think > this is probably something a lot of other people might have a problem > understanding as well when they first start looking into the FontForge > source code. I'd say it increases the learning curve and reduces the > possibility of more developers contributing to this project. Indeed. My first guess is that the widget set is based on early versions of GDK and tries to avoid dependent libraries as much as possible so that FontForge could interact directly with X. Some clues here is probably looking at xpm xbm stuff in the gutils folder, which were more common in 200x and forgotten now. 2000...2012 you're probably looking at code that at some level talks to or through the Xwindow system. Targetting X would avoid the differences between Gnome and KDE. If you look at 2012 code, some of these GUI choices are optional, not required. > Maybe you should have a more in depth overview on which libraries are > used and how they work in the docs? Smaller pool of developers. Time & resources - where is time best used. A lot has gone into fighting fires and improvements. > Some of my questions are: > 1. What is the name of this non-standard widget set? 2. Is there any > documentation for how it works? My first guess is, look at the early versions of the GDK toolkit. Look at the output results, then parse output to reduce dependencies. > 3. How is a window created using this widget set? > 4. Where do I find the event listeners? Is it a signal/slot pattern, or > something else? > > Hope I'm not spamming with too basic stuff here, but I've been trying to > get into the code without any luck several times now, and I'm starting > to think this is something other people might want to know about as > well. - Thor Arisland Start with an early TAG point, less code to look at. I mention 20120731 as latest GW code before we started supporting it, therefore different coding styles, ideas, etc. are mixed into later code. Hope this helps. Joe |
From: Joe <di...@jo...> - 2019-07-10 22:05:07
|
Was looking at cmake homepage. It tends to show where the future direction may be. Didn't try checking distribution for cake due to limited WiFi last couple days |
From: T J <jt...@ou...> - 2019-07-09 11:28:30
|
This is incorrect. CMake is pretty widely supported, and it definitely has 32-bit support. ________________________________ From: Joe <di...@jo...> Sent: Tuesday, July 9, 2019 7:35:21 PM To: FontForge developers' discussions Subject: Re: [fontforge-devel] Build system changes Looking at CMAKE it appears it only supports a limited set of choices. For example, I'm currently travelling with a mini laptop and I don't see 32 bit as a choice. |
From: Joe <di...@jo...> - 2019-07-09 09:52:20
|
Looking at CMAKE it appears it only supports a limited set of choices. For example, I'm currently travelling with a mini laptop and I don't see 32 bit as a choice. |
From: Tim L. <tl...@we...> - 2019-07-08 15:45:01
|
This shouldn’t be a problem for any pkgsrc system (e.g. NetBSD, Minix, etc). If cmake is listed as a dependency, it will be built if needed and continue from there. -- Tim Larson From: T J <jt...@ou...> Sent: Monday, July 08, 2019 4:58 AM To: FontForge developers' discussions <fon...@li...> Subject: [fontforge-devel] Build system changes Hi all, In case I missed highlighting this the previous time around, I will (re)state my intentions: It is my goal to completely replace the current autotools build system in FontForge with CMake, targeting a minimum version of likely either 3.1 or 3.4. I have detailed the reasons why here: https://github.com/fontforge/fontforge/issues/3512 But my aim out of this is primarily: * Significantly improved build times, especially on platforms like Windows * Potentially making it easier to target e.g. MSVC for native Python integration on Windows * Making the build system more maintainable I don’t exactly know at what point this will land, but I have every intention of making it happen. CMake >= 3.4 is widely supported on all recent releases of Debian, Ubuntu and RHEL. Windows and MacOS have easy access to the latest version of CMake. For distros where this is not available by default, my take is that either a newer version of CMake just needs to be installed (say via a PPA), or they should use older releases of FontForge. Thanks, Jeremy |
From: Apostolos S. <ijd...@gm...> - 2019-07-08 15:18:28
|
Στις Δευ, 8 Ιουλ 2019 στις 12:58 μ.μ., ο/η T J <jt...@ou...> έγραψε: > > > > CMake >= 3.4 is widely supported on all recent releases of Debian, Ubuntu > and RHEL. Windows and MacOS have easy access to the latest version of > CMake. For distros where this is not available by default, my take is that > either a newer version of CMake just needs to be installed (say via a PPA), > or they should use older releases of FontForge. > > > Just remember that this is a generic tool that thousands of people use and also there are people like me that use OpenIndiana (OpenSolaris) that want to be able to continue using FF. On my platform $ cmake --version cmake version 3.12.4 CMake suite maintained and supported by Kitware (kitware.com/cmake). So I am OK with this... A.S. -- Apostolos Syropoulos Xanthi, GREECE |
From: Thor C. <tca...@gm...> - 2019-07-08 12:45:06
|
Hi, this might seem like some very basic stuff here, but I've been skimming through the code just to get an overview on how FontForge is built and some really basic stuff just seems difficult to discern from the code and documentation alone. I think this project could learn a lot from InkScape when it comes to documentation and code structure. Anyway, the first thing I do when I try and understand code is to look for the GUI code so I can see how the UI fits with the functionality of the program. For FontForge this has been rather difficult, all I could find about the GUI from the docs is this part from the FAQ: * "**Why doesn't it use the native MS Windows or Mac windowing system?* - *FontForge is not a commercial product and is not bound by the constraints of the market.* - *Doing that port doesn't interest me.* - *I don't have time nor do I have the skill to take that task on.* - *I'd like to encourage people to use Linux/unix* *Of course, if I were to use either gtk or qt <https://fontforge.github.io/faq.html#widget-set> some of the difficulties of porting would vanish. But unfortunately I don't like either of those widget sets.* *Now... if you would like to do the port, that would be wonderful. I encourage you to do so.* * Why is FontForge based on a non-standard widget set? ..."* None of this information explains what this widget set is or how it draws its GUI, the only hint I've found is that it uses Cairo, somewhere in the code it looks like it draws the GUI pixel by pixel, and there's a GDraw directory with some datatypes such as GWindow and GWidget that seem to be related to the UI, but trying to follow the function calls and see where it ends it's very difficult to get an idea on how the GUI code works. Since I'm still confused about this, I think this is probably something a lot of other people might have a problem understanding as well when they first start looking into the FontForge source code. I'd say it increases the learning curve and reduces the possibility of more developers contributing to this project. Maybe you should have a more in depth overview on which libraries are used and how they work in the docs? Some of my questions are: 1. What is the name of this non-standard widget set? 2. Is there any documentation for how it works? 3. How is a window created using this widget set? 4. Where do I find the event listeners? Is it a signal/slot pattern, or something else? Hope I'm not spamming with too basic stuff here, but I've been trying to get into the code without any luck several times now, and I'm starting to think this is something other people might want to know about as well. - Thor Arisland |
From: T J <jt...@ou...> - 2019-07-08 09:57:37
|
Hi all, In case I missed highlighting this the previous time around, I will (re)state my intentions: It is my goal to completely replace the current autotools build system in FontForge with CMake, targeting a minimum version of likely either 3.1 or 3.4. I have detailed the reasons why here: https://github.com/fontforge/fontforge/issues/3512 But my aim out of this is primarily: * Significantly improved build times, especially on platforms like Windows * Potentially making it easier to target e.g. MSVC for native Python integration on Windows * Making the build system more maintainable I don’t exactly know at what point this will land, but I have every intention of making it happen. CMake >= 3.4 is widely supported on all recent releases of Debian, Ubuntu and RHEL. Windows and MacOS have easy access to the latest version of CMake. For distros where this is not available by default, my take is that either a newer version of CMake just needs to be installed (say via a PPA), or they should use older releases of FontForge. Thanks, Jeremy |
From: Skef I. <gi...@sk...> - 2019-06-04 17:56:40
|
I've thought about this a little bit. It points down the road of a text or array/dictionary structure "language" for specifying custom dialogs. If there were already such a thing in wide use, FontForge could grab or borrow it. That might be a sensible project, and could be supported into the future. However, poking around I didn't find anything like that in use. Since it's such an obvious direction that makes me suspect that other projects have gone further down that road and then abandoned it. Anyway, there's another viable approach that would be easier to support -- probably pretty straightforward. Using RPyC (or whatever equivalent) one could start an external process and communicate back and forth with it. It could then use whatever graphics layer it wanted. The FontForge side support you'd want to make things clean would be: 1. An interface for retrieving window dimensions relative to the screen (tricky in some cases), and 2. An interface for a modal "grab" and "ungrab", to temporarily freeze the interface on the FontForge side. Like adding support for GTK, this would let you do almost anything, including add non-modal windows if you wanted. Skef On 6/4/19 5:06 AM, Abraham Lee wrote: > Hey, Fred! > > On Mon, Jun 3, 2019 at 4:17 AM Fred Brennan <cop...@ki... > <mailto:cop...@ki...>> wrote: > > We talked about getting PyGTK support in https://github.com/fontforge/ > fontforge/issues/3663 > <https://github.com/fontforge/fontforge/issues/3663>, which might > interest you considering your interest in > using foreign GUI platforms inside FontForge's python interface. > > > Whatever works, but if energy would be spent better on other things > that need to be done first, that’s ok, too. This is a wishlist thing > for me. > > My particular usage would prefer, at least, to be able to make > slightly more populated input popups where I can have text inputs, > drop downs, radio buttons, etc., all in a single window. At the > moment, using the few popup types available, I have to use anywhere > from 2-6 individual input text boxes because the popup only allows for > one at a time. It’s not a huge deal, just a convenience thing. > > Ideally, being able to have a live connection between the outline > editor and a separate input popup, that would allow me to “apply” an > affect (similar to the current transform GUI) would be nice, but not > critical. > > I’m grateful for whatever can be done since I have about 30-50 plugins > I regularly use and being able to streamline them would be great, but > don’t feel like this needs to be top priority. This change to Python 3 > is a good one and it finally gives me a solid reason to port my own > code to Python 3. > > Best, > Abraham > > > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html |
From: Abraham L. <tis...@gm...> - 2019-06-04 12:28:44
|
Yep. I know that’s not ideal, but it’s what I need to use for the time being for a number of reasons. On Tue, Jun 4, 2019 at 6:24 AM Frank Trampe <fra...@gm...> wrote: > Are you on Windows? > > On Tue, Jun 4, 2019, 07:07 Abraham Lee <tis...@gm...> > wrote: > >> Hey, Fred! >> >> On Mon, Jun 3, 2019 at 4:17 AM Fred Brennan <cop...@ki...> wrote: >> >>> We talked about getting PyGTK support in https://github.com/fontforge/ >>> fontforge/issues/3663 >>> <https://github.com/fontforge/fontforge/issues/3663>, which might >>> interest you considering your interest in >>> using foreign GUI platforms inside FontForge's python interface. >> >> >> Whatever works, but if energy would be spent better on other things that >> need to be done first, that’s ok, too. This is a wishlist thing for me. >> >> My particular usage would prefer, at least, to be able to make slightly >> more populated input popups where I can have text inputs, drop downs, radio >> buttons, etc., all in a single window. At the moment, using the few popup >> types available, I have to use anywhere from 2-6 individual input text >> boxes because the popup only allows for one at a time. It’s not a huge >> deal, just a convenience thing. >> >> Ideally, being able to have a live connection between the outline editor >> and a separate input popup, that would allow me to “apply” an affect >> (similar to the current transform GUI) would be nice, but not critical. >> >> I’m grateful for whatever can be done since I have about 30-50 plugins I >> regularly use and being able to streamline them would be great, but don’t >> feel like this needs to be top priority. This change to Python 3 is a good >> one and it finally gives me a solid reason to port my own code to Python 3. >> >> Best, >> Abraham >> >>> _______________________________________________ > > >> fontforge-devel mailing list >> fon...@li... >> https://lists.sourceforge.net/lists/listinfo/fontforge-devel >> http://fontforge.10959.n7.nabble.com/Developer-f3.html >> > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: Frank T. <fra...@gm...> - 2019-06-04 12:23:37
|
Are you on Windows? On Tue, Jun 4, 2019, 07:07 Abraham Lee <tis...@gm...> wrote: > Hey, Fred! > > On Mon, Jun 3, 2019 at 4:17 AM Fred Brennan <cop...@ki...> wrote: > >> We talked about getting PyGTK support in https://github.com/fontforge/ >> fontforge/issues/3663 >> <https://github.com/fontforge/fontforge/issues/3663>, which might >> interest you considering your interest in >> using foreign GUI platforms inside FontForge's python interface. > > > Whatever works, but if energy would be spent better on other things that > need to be done first, that’s ok, too. This is a wishlist thing for me. > > My particular usage would prefer, at least, to be able to make slightly > more populated input popups where I can have text inputs, drop downs, radio > buttons, etc., all in a single window. At the moment, using the few popup > types available, I have to use anywhere from 2-6 individual input text > boxes because the popup only allows for one at a time. It’s not a huge > deal, just a convenience thing. > > Ideally, being able to have a live connection between the outline editor > and a separate input popup, that would allow me to “apply” an affect > (similar to the current transform GUI) would be nice, but not critical. > > I’m grateful for whatever can be done since I have about 30-50 plugins I > regularly use and being able to streamline them would be great, but don’t > feel like this needs to be top priority. This change to Python 3 is a good > one and it finally gives me a solid reason to port my own code to Python 3. > > Best, > Abraham > >> _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: Abraham L. <tis...@gm...> - 2019-06-04 12:06:35
|
Hey, Fred! On Mon, Jun 3, 2019 at 4:17 AM Fred Brennan <cop...@ki...> wrote: > We talked about getting PyGTK support in https://github.com/fontforge/ > fontforge/issues/3663 <https://github.com/fontforge/fontforge/issues/3663>, > which might interest you considering your interest in > using foreign GUI platforms inside FontForge's python interface. Whatever works, but if energy would be spent better on other things that need to be done first, that’s ok, too. This is a wishlist thing for me. My particular usage would prefer, at least, to be able to make slightly more populated input popups where I can have text inputs, drop downs, radio buttons, etc., all in a single window. At the moment, using the few popup types available, I have to use anywhere from 2-6 individual input text boxes because the popup only allows for one at a time. It’s not a huge deal, just a convenience thing. Ideally, being able to have a live connection between the outline editor and a separate input popup, that would allow me to “apply” an affect (similar to the current transform GUI) would be nice, but not critical. I’m grateful for whatever can be done since I have about 30-50 plugins I regularly use and being able to streamline them would be great, but don’t feel like this needs to be top priority. This change to Python 3 is a good one and it finally gives me a solid reason to port my own code to Python 3. Best, Abraham > |
From: Fred B. <cop...@ki...> - 2019-06-03 10:17:10
|
We talked about getting PyGTK support in https://github.com/fontforge/ fontforge/issues/3663, which might interest you considering your interest in using foreign GUI platforms inside FontForge's python interface. On Sunday, June 2, 2019 9:52:06 AM PST Abraham Lee wrote: > That’s totally ok. I can manage without it. Just hoping it can happen > someday. Thanks again! |
From: Abraham L. <tis...@gm...> - 2019-06-02 01:52:26
|
That’s totally ok. I can manage without it. Just hoping it can happen someday. Thanks again! On Sat, Jun 1, 2019 at 7:29 PM T J <jt...@ou...> wrote: > Hi Abraham, > > > > Unfortunately not yet. I have some build system overhaul changes planned, > but that is still a way off. With that, I am hoping it will be easier to > target compiling against the ‘native’ Python Windows installation, which > will allow what you are wishing for. > > > > Thanks, > > Jeremy > > *From: *Abraham Lee <tis...@gm...> > *Sent: *Sunday, 2 June 2019 6:17 AM > *To: *FontForge developers' discussions > <fon...@li...> > *Subject: *Re: [fontforge-devel] Making Python3 the default > > > > Hey, Jeremy! > > > > On Sat, Jun 1, 2019 at 5:58 AM T J <jt...@ou...> wrote: > > With support for Python 2 dropping off, in the next release of FontForge, > the Windows build will use the Python 3 binding instead of the Python 2 > binding, as it has used in the past. > > > > I was thinking about this lately. Thanks for taking the initiative to make > this happen. Will the change allow for a more “native” state? Meaning, will > it make it easier to use external packages, installed via pip or otherwise? > And being able to use other graphics packages (like tcl, wx, etc.) would be > really nice to do. > > > > Thanks for all you do! > > > > Best, > > Abraham > > > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html > |
From: T J <jt...@ou...> - 2019-06-02 01:29:45
|
________________________________ From: Abraham Lee <tis...@gm...> Sent: Sunday, June 2, 2019 6:16:30 AM To: FontForge developers' discussions Subject: Re: [fontforge-devel] Making Python3 the default Hey, Jeremy! On Sat, Jun 1, 2019 at 5:58 AM T J <jt...@ou...<mailto:jt...@ou...>> wrote: With support for Python 2 dropping off, in the next release of FontForge, the Windows build will use the Python 3 binding instead of the Python 2 binding, as it has used in the past. I was thinking about this lately. Thanks for taking the initiative to make this happen. Will the change allow for a more “native” state? Meaning, will it make it easier to use external packages, installed via pip or otherwise? And being able to use other graphics packages (like tcl, wx, etc.) would be really nice to do. Thanks for all you do! Best, Abraham |
From: T J <jt...@ou...> - 2019-06-02 01:28:39
|
Hi Abraham, Unfortunately not yet. I have some build system overhaul changes planned, but that is still a way off. With that, I am hoping it will be easier to target compiling against the ‘native’ Python Windows installation, which will allow what you are wishing for. Thanks, Jeremy From: Abraham Lee<mailto:tis...@gm...> Sent: Sunday, 2 June 2019 6:17 AM To: FontForge developers' discussions<mailto:fon...@li...> Subject: Re: [fontforge-devel] Making Python3 the default Hey, Jeremy! On Sat, Jun 1, 2019 at 5:58 AM T J <jt...@ou...<mailto:jt...@ou...>> wrote: With support for Python 2 dropping off, in the next release of FontForge, the Windows build will use the Python 3 binding instead of the Python 2 binding, as it has used in the past. I was thinking about this lately. Thanks for taking the initiative to make this happen. Will the change allow for a more “native” state? Meaning, will it make it easier to use external packages, installed via pip or otherwise? And being able to use other graphics packages (like tcl, wx, etc.) would be really nice to do. Thanks for all you do! Best, Abraham |
From: Abraham L. <tis...@gm...> - 2019-06-01 20:16:49
|
Hey, Jeremy! On Sat, Jun 1, 2019 at 5:58 AM T J <jt...@ou...> wrote: > With support for Python 2 dropping off, in the next release of FontForge, > the Windows build will use the Python 3 binding instead of the Python 2 > binding, as it has used in the past. > I was thinking about this lately. Thanks for taking the initiative to make this happen. Will the change allow for a more “native” state? Meaning, will it make it easier to use external packages, installed via pip or otherwise? And being able to use other graphics packages (like tcl, wx, etc.) would be really nice to do. Thanks for all you do! Best, Abraham |
From: T J <jt...@ou...> - 2019-06-01 11:58:03
|
Hi all, With support for Python 2 dropping off, in the next release of FontForge, the Windows build will use the Python 3 binding instead of the Python 2 binding, as it has used in the past. It is likely that the Mac build will follow suit, but this will be decided closer to when the next release is cut. With that, I’d propose that the next release will be the last release that actually supports Python 2 (if only by compiling it yourself). From that point on, we should move towards removing Python 2 support altogether. If you have any questions/comments/concerns on this, let me know. Thanks, Jeremy |
From: Maurizio M. G. <mm...@vi...> - 2019-04-27 10:50:11
|
Thanks for the reply and the suggestion. In fact, restarting from scratch with a fresh git clone (and with the configure command you suggested), I could compile everything without any compilation error (a fair number of warnings, but no error). So, there seems to be some kind of problem with legacy cloned repos, but probably nothing that a clean (or a fresh clone) cannot fix. Thanks again, MMG On 27/04/2019 00:28, Skef Iterum wrote: > I've seen this third issue a couple of times myself with recent repo > versions, but it seems to be related to incremental configure/builds > somehow. I can usually work around it by doing a thorough git clean > (with -X and -d as needed) and starting over. (Which is not to say > that there isn't a problem that needs to be fixed, of course.) > > Note that python scripting is now built by default. I think the > preferred way to choose a version is currently: > > PYTHON=python3 ./configure --prefix=$HOME/bin > > Where "python3" is the python executable of the version you want to use. > > Skef > > On 4/26/19 2:05 PM, Maurizio M. Gavioli wrote: >> Hello, >> >> coming up-to-date with fontforge again after some years and I noticed >> a few compilation 'show-stoppers'. I am posting each issue in a >> separate mail for clarity. >> >> System: Linux Mint 19.1 (based on Ubuntu bionic) with gcc/g++ 7.3.0, >> make 4.1, automake 1.15.1 (in case any of these is relevant). >> >> Issue 3: >> >> After running >> >> ./configure --prefix=$HOME/bin --enable-python-scripting=3 >> >> make >> >> I get the following errors: >> >> ----- start of quote ----- >> >> make[2]: Entering directory '.../fontforge/gutils' >> CC libgutils_la-fsys.lo >> In file included from fsys.c:38:0: >> ../lib/unistd.h:596:3: error: #error "Please include config.h first." >> #error "Please include config.h first." >> ^~~~~ >> In file included from fsys.c:28:0: > |
From: Skef I. <gi...@sk...> - 2019-04-26 22:28:39
|
I've seen this third issue a couple of times myself with recent repo versions, but it seems to be related to incremental configure/builds somehow. I can usually work around it by doing a thorough git clean (with -X and -d as needed) and starting over. (Which is not to say that there isn't a problem that needs to be fixed, of course.) Note that python scripting is now built by default. I think the preferred way to choose a version is currently: PYTHON=python3 ./configure --prefix=$HOME/bin Where "python3" is the python executable of the version you want to use. Skef On 4/26/19 2:05 PM, Maurizio M. Gavioli wrote: > Hello, > > coming up-to-date with fontforge again after some years and I noticed > a few compilation 'show-stoppers'. I am posting each issue in a > separate mail for clarity. > > System: Linux Mint 19.1 (based on Ubuntu bionic) with gcc/g++ 7.3.0, > make 4.1, automake 1.15.1 (in case any of these is relevant). > > Issue 3: > > After running > > ./configure --prefix=$HOME/bin --enable-python-scripting=3 > > make > > I get the following errors: > > ----- start of quote ----- > > make[2]: Entering directory '.../fontforge/gutils' > CC libgutils_la-fsys.lo > In file included from fsys.c:38:0: > ../lib/unistd.h:596:3: error: #error "Please include config.h first." > #error "Please include config.h first." > ^~~~~ > In file included from fsys.c:28:0: > ../lib/unistd.h:1227:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or > ‘__attribute__’ before ‘extern’ > _GL_CXXALIAS_SYS_CAST (gethostname, int, (char *name, size_t len)); > ^ > In file included from /usr/include/glib-2.0/glib/gtypes.h:32:0, > from /usr/include/glib-2.0/glib/galloca.h:32, > from /usr/include/glib-2.0/glib.h:30, > from ../inc/ffglib.h:27, > from fsys.c:39: > /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:37:1: error: > expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘typedef’ > typedef signed char gint8; > ^~~~~~~ > In file included from /usr/include/glib-2.0/glib-object.h:28:0, > from ../inc/ffglib.h:28, > from fsys.c:39: > /usr/include/glib-2.0/gobject/gparamspecs.h:623:3: error: unknown type > name ‘gint8’ > gint8 minimum; > ^~~~~ > ----- end of quote ----- > > the last error (about undefined `gint8`) is repeated several times for > several different source files, but presumably has always the same > origin (probably the previous error with glibconfig.h). > > I tried to add #include "config.h" in fsys.c before including > unistd.h, but this didn't change anything. > > As I ended working with C a few decades ago, fontforge code base is > huge and something unusual is being done with unistd.h (a custom > wrapper is added around the system header), I have no idea where to > start looking for a solution. Any suggestion will be appreciated. Thanks! > > MMG > > > > > _______________________________________________ > fontforge-devel mailing list > fon...@li... > https://lists.sourceforge.net/lists/listinfo/fontforge-devel > http://fontforge.10959.n7.nabble.com/Developer-f3.html |