Loading ...
Sorry, an error occurred while loading the content.
 

Linux port

Expand Messages
  • ivucica
    Hi all, I m completely new to Frontier and to OPML. I m primarily responding to Adam Curry s bat signal to help with the GNU/Linux port. I ve done some
    Message 1 of 17 , Jan 4, 2012
      Hi all,

      I'm completely new to Frontier and to OPML. I'm primarily responding to Adam Curry's bat signal to help with the GNU/Linux port.

      I've done some preliminary digging around the current Frontier base and reading of this list. I don't think it can easily be salvaged and ported to GNU/Linux, at least not by an external individual new to the codebase; I don't see any way to refactor the code quickly to separate out the Windows and Mac specific code.

      Seeing the Xcode project in the source code distribution, I had high hopes that OPML Editor had at least some Cocoa code in it, and that it just interfaced with the C codebase. Unfortunately, it seems that it is completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't seem to be isolated in any way.

      I'm fully aware that I'm preaching to the choir. So here's what I propose.

      I'd love to explore writing a basic Cocoa app for writing OPML. This would mean modernized user interface under OS X. At the same time, I'd maintain the code to compile under the excellent GNUstep environment. This would mean that the same code would run under OS X and under GNU/Linux. At the same time, since GNUstep apps work under Windows and various variants of BSD, this editor would be supported on those platforms as well.

      However!

      As I said, I am completely new to Frontier and OPML. I don't know what people exactly use it for. I don't know what people's workflow is.

      I also don't want to work on separating Frontier's GUI code from Frontier's various core modules (from what I understand: scripting, database, and perhaps more). If people are willing to provide a reasonable, small set of extensible callbacks to drive the GUI code, such as "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple integration.

      When determining how we can proceed, remember that Objective-C, Python and many other languages allow dynamic instantiation of classes using names specified in strings. So there are portions that could probably be done by passing strings around when creating menu items, buttons, outline items, rather than have tight GUI integration just to do things like these.

      To determine how to proceed, and whether to proceed at all, I need feedback from Frontier users - especially Adam, since it's his call that I'm responding.

      - What do you use Frontier for?
      - How do you use the OPML Editor?
      - I understand that OPML Editor is tightly integrated with Frontier, can be scripted, and in fact most of its interface is Frontier-generated. How essential is this?
      - Would it be sufficient if only a few commands were integrated?
      - Is tight integration essential?
      - Is WYSIWYG HTML editor integration inside the outline view essential?

      If nothing else, note that I'm willing to write a basic cross-platform OPML outliner using Objective-C language and Cocoa APIs, which means this editor would run on OS X, and on various GNUstep-supported platforms. Any postprocessing could then be done in other ways.

      Please tell me your thoughts.
    • dwiner
      You can get an idea of what we use Frontier for by keeping an eye on this river. http://river.frontiernews.org/ Also, it is itself a Frontier application. :-)
      Message 2 of 17 , Jan 6, 2012
        You can get an idea of what we use Frontier for by keeping an eye on this river.

        http://river.frontiernews.org/

        Also, it is itself a Frontier application. :-)

        Dave




        --- In frontierkernel@yahoogroups.com, "ivucica" <ivucica@...> wrote:
        >
        > Hi all,
        >
        > I'm completely new to Frontier and to OPML. I'm primarily responding to Adam Curry's bat signal to help with the GNU/Linux port.
        >
        > I've done some preliminary digging around the current Frontier base and reading of this list. I don't think it can easily be salvaged and ported to GNU/Linux, at least not by an external individual new to the codebase; I don't see any way to refactor the code quickly to separate out the Windows and Mac specific code.
        >
        > Seeing the Xcode project in the source code distribution, I had high hopes that OPML Editor had at least some Cocoa code in it, and that it just interfaced with the C codebase. Unfortunately, it seems that it is completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't seem to be isolated in any way.
        >
        > I'm fully aware that I'm preaching to the choir. So here's what I propose.
        >
        > I'd love to explore writing a basic Cocoa app for writing OPML. This would mean modernized user interface under OS X. At the same time, I'd maintain the code to compile under the excellent GNUstep environment. This would mean that the same code would run under OS X and under GNU/Linux. At the same time, since GNUstep apps work under Windows and various variants of BSD, this editor would be supported on those platforms as well.
        >
        > However!
        >
        > As I said, I am completely new to Frontier and OPML. I don't know what people exactly use it for. I don't know what people's workflow is.
        >
        > I also don't want to work on separating Frontier's GUI code from Frontier's various core modules (from what I understand: scripting, database, and perhaps more). If people are willing to provide a reasonable, small set of extensible callbacks to drive the GUI code, such as "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple integration.
        >
        > When determining how we can proceed, remember that Objective-C, Python and many other languages allow dynamic instantiation of classes using names specified in strings. So there are portions that could probably be done by passing strings around when creating menu items, buttons, outline items, rather than have tight GUI integration just to do things like these.
        >
        > To determine how to proceed, and whether to proceed at all, I need feedback from Frontier users - especially Adam, since it's his call that I'm responding.
        >
        > - What do you use Frontier for?
        > - How do you use the OPML Editor?
        > - I understand that OPML Editor is tightly integrated with Frontier, can be scripted, and in fact most of its interface is Frontier-generated. How essential is this?
        > - Would it be sufficient if only a few commands were integrated?
        > - Is tight integration essential?
        > - Is WYSIWYG HTML editor integration inside the outline view essential?
        >
        > If nothing else, note that I'm willing to write a basic cross-platform OPML outliner using Objective-C language and Cocoa APIs, which means this editor would run on OS X, and on various GNUstep-supported platforms. Any postprocessing could then be done in other ways.
        >
        > Please tell me your thoughts.
        >
      • Ivan Vučica
        Hi Dave! After receiving Adam s response, I ve began work on a separate Cocoa-based OPML application which ll be extremely easy to port to GNU/Linux using
        Message 3 of 17 , Jan 7, 2012
          Hi Dave!

          After receiving Adam's response, I've began work on a separate Cocoa-based OPML application which'll be extremely easy to port to GNU/Linux using GNUstep. I decided against porting Frontier itself to Cocoa and GNUstep, since I'm too new to the platform, and the time I'll have available for spending on this endeavor is probably very, very limited.

          Since less than one day of work went into it, it's still very basic. Its source code is available here:
            http://bitbucket.org/ivucica/opml

          - Is there a way to separate Frontier scripting core, including the database, from the GUI? 
          - Having command-line version of Frontier that runs on any POSIX system would mean one could run server portions of various tools without porting the GUI. What's the situation there?
          - Is there some documentation on how a non-Frontier program can interact with Frontier servers, or various tools written for Frontier?

          On a side note, I couldn't get WorldOutline nor Scripting2 to work yesterday. I've updated OPML Editor, and then I tried installing WorldOutline, but without success. This was done under OS X.

          On Sat, Jan 7, 2012 at 02:10, dwiner <dave.winer@...> wrote:
           

          You can get an idea of what we use Frontier for by keeping an eye on this river.

          http://river.frontiernews.org/

          Also, it is itself a Frontier application. :-)

          Dave



          --- In frontierkernel@yahoogroups.com, "ivucica" <ivucica@...> wrote:
          >
          > Hi all,
          >
          > I'm completely new to Frontier and to OPML. I'm primarily responding to Adam Curry's bat signal to help with the GNU/Linux port.
          >
          > I've done some preliminary digging around the current Frontier base and reading of this list. I don't think it can easily be salvaged and ported to GNU/Linux, at least not by an external individual new to the codebase; I don't see any way to refactor the code quickly to separate out the Windows and Mac specific code.
          >
          > Seeing the Xcode project in the source code distribution, I had high hopes that OPML Editor had at least some Cocoa code in it, and that it just interfaced with the C codebase. Unfortunately, it seems that it is completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't seem to be isolated in any way.
          >
          > I'm fully aware that I'm preaching to the choir. So here's what I propose.
          >
          > I'd love to explore writing a basic Cocoa app for writing OPML. This would mean modernized user interface under OS X. At the same time, I'd maintain the code to compile under the excellent GNUstep environment. This would mean that the same code would run under OS X and under GNU/Linux. At the same time, since GNUstep apps work under Windows and various variants of BSD, this editor would be supported on those platforms as well.
          >
          > However!
          >
          > As I said, I am completely new to Frontier and OPML. I don't know what people exactly use it for. I don't know what people's workflow is.
          >
          > I also don't want to work on separating Frontier's GUI code from Frontier's various core modules (from what I understand: scripting, database, and perhaps more). If people are willing to provide a reasonable, small set of extensible callbacks to drive the GUI code, such as "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple integration.
          >
          > When determining how we can proceed, remember that Objective-C, Python and many other languages allow dynamic instantiation of classes using names specified in strings. So there are portions that could probably be done by passing strings around when creating menu items, buttons, outline items, rather than have tight GUI integration just to do things like these.
          >
          > To determine how to proceed, and whether to proceed at all, I need feedback from Frontier users - especially Adam, since it's his call that I'm responding.
          >
          > - What do you use Frontier for?
          > - How do you use the OPML Editor?
          > - I understand that OPML Editor is tightly integrated with Frontier, can be scripted, and in fact most of its interface is Frontier-generated. How essential is this?
          > - Would it be sufficient if only a few commands were integrated?
          > - Is tight integration essential?
          > - Is WYSIWYG HTML editor integration inside the outline view essential?
          >
          > If nothing else, note that I'm willing to write a basic cross-platform OPML outliner using Objective-C language and Cocoa APIs, which means this editor would run on OS X, and on various GNUstep-supported platforms. Any postprocessing could then be done in other ways.
          >
          > Please tell me your thoughts.
          >




          --
          Ivan Vučica - ivan@...


        • Ted Howard
          Ivan, For what it s worth, the OPML Editor windows binary will run on linux via Wine. It s not the most stable set-up, but I have had it running. Trying to
          Message 4 of 17 , Jan 7, 2012
            Ivan,

            For what it's worth, the OPML Editor windows binary will run on linux via Wine. It's not the most stable set-up, but I have had it running. Trying to debug the wine issues might give you a higher ROI for your time.

            Ted

            On Jan 7, 2012, at 11:49 AM, Ivan Vučica wrote:

             

            Hi Dave!


            After receiving Adam's response, I've began work on a separate Cocoa-based OPML application which'll be extremely easy to port to GNU/Linux using GNUstep. I decided against porting Frontier itself to Cocoa and GNUstep, since I'm too new to the platform, and the time I'll have available for spending on this endeavor is probably very, very limited.

            Since less than one day of work went into it, it's still very basic. Its source code is available here:
              http://bitbucket.org/ivucica/opml

            - Is there a way to separate Frontier scripting core, including the database, from the GUI? 
            - Having command-line version of Frontier that runs on any POSIX system would mean one could run server portions of various tools without porting the GUI. What's the situation there?
            - Is there some documentation on how a non-Frontier program can interact with Frontier servers, or various tools written for Frontier?

            On a side note, I couldn't get WorldOutline nor Scripting2 to work yesterday. I've updated OPML Editor, and then I tried installing WorldOutline, but without success. This was done under OS X.

            On Sat, Jan 7, 2012 at 02:10, dwiner <dave.winer@...> wrote:
             

            You can get an idea of what we use Frontier for by keeping an eye on this river.

            http://river.frontiernews.org/

            Also, it is itself a Frontier application. :-)

            Dave



            --- In frontierkernel@yahoogroups.com, "ivucica" <ivucica@...> wrote:
            >
            > Hi all,
            >
            > I'm completely new to Frontier and to OPML. I'm primarily responding to Adam Curry's bat signal to help with the GNU/Linux port.
            >
            > I've done some preliminary digging around the current Frontier base and reading of this list. I don't think it can easily be salvaged and ported to GNU/Linux, at least not by an external individual new to the codebase; I don't see any way to refactor the code quickly to separate out the Windows and Mac specific code.
            >
            > Seeing the Xcode project in the source code distribution, I had high hopes that OPML Editor had at least some Cocoa code in it, and that it just interfaced with the C codebase. Unfortunately, it seems that it is completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't seem to be isolated in any way.
            >
            > I'm fully aware that I'm preaching to the choir. So here's what I propose.
            >
            > I'd love to explore writing a basic Cocoa app for writing OPML. This would mean modernized user interface under OS X. At the same time, I'd maintain the code to compile under the excellent GNUstep environment. This would mean that the same code would run under OS X and under GNU/Linux. At the same time, since GNUstep apps work under Windows and various variants of BSD, this editor would be supported on those platforms as well.
            >
            > However!
            >
            > As I said, I am completely new to Frontier and OPML. I don't know what people exactly use it for. I don't know what people's workflow is.
            >
            > I also don't want to work on separating Frontier's GUI code from Frontier's various core modules (from what I understand: scripting, database, and perhaps more). If people are willing to provide a reasonable, small set of extensible callbacks to drive the GUI code, such as "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple integration.
            >
            > When determining how we can proceed, remember that Objective-C, Python and many other languages allow dynamic instantiation of classes using names specified in strings. So there are portions that could probably be done by passing strings around when creating menu items, buttons, outline items, rather than have tight GUI integration just to do things like these.
            >
            > To determine how to proceed, and whether to proceed at all, I need feedback from Frontier users - especially Adam, since it's his call that I'm responding.
            >
            > - What do you use Frontier for?
            > - How do you use the OPML Editor?
            > - I understand that OPML Editor is tightly integrated with Frontier, can be scripted, and in fact most of its interface is Frontier-generated. How essential is this?
            > - Would it be sufficient if only a few commands were integrated?
            > - Is tight integration essential?
            > - Is WYSIWYG HTML editor integration inside the outline view essential?
            >
            > If nothing else, note that I'm willing to write a basic cross-platform OPML outliner using Objective-C language and Cocoa APIs, which means this editor would run on OS X, and on various GNUstep-supported platforms. Any postprocessing could then be done in other ways.
            >
            > Please tell me your thoughts.
            >





            --
            Ivan Vučica - ivan@...




          • Ivan Vučica
            Hi Ted, running in Wine is cool, but it s prone to disruptive changes made by Wine folks. I m also interested in bringing a better user experience to Mac, as
            Message 5 of 17 , Jan 7, 2012
              Hi Ted,

              running in Wine is cool, but it's prone to disruptive changes made by Wine folks. I'm also interested in bringing a better user experience to Mac, as well as future-proofing the Mac OPML editing. Who knows whether Carbon will still be there in 10.8? Who knows whether 32-bit code will be runnable on 10.8? (Apple may definitely deprecate it.)

              Separating the GUI from generic code (if not already possible) is also generally a good idea for running on headless servers. And the ability to run native, GUI-less tools on Linux servers may also mean everything is cheaper due to licensing fees being lower.

              Plus, running under Wine and debugging issues is not as fun as writing something new for the ecosystem ;)

              On Sat, Jan 7, 2012 at 18:54, Ted Howard <tedchoward@...> wrote:
               

              Ivan,


              For what it's worth, the OPML Editor windows binary will run on linux via Wine. It's not the most stable set-up, but I have had it running. Trying to debug the wine issues might give you a higher ROI for your time.

              Ted

              On Jan 7, 2012, at 11:49 AM, Ivan Vučica wrote:

               

              Hi Dave!


              After receiving Adam's response, I've began work on a separate Cocoa-based OPML application which'll be extremely easy to port to GNU/Linux using GNUstep. I decided against porting Frontier itself to Cocoa and GNUstep, since I'm too new to the platform, and the time I'll have available for spending on this endeavor is probably very, very limited.

              Since less than one day of work went into it, it's still very basic. Its source code is available here:
                http://bitbucket.org/ivucica/opml

              - Is there a way to separate Frontier scripting core, including the database, from the GUI? 
              - Having command-line version of Frontier that runs on any POSIX system would mean one could run server portions of various tools without porting the GUI. What's the situation there?
              - Is there some documentation on how a non-Frontier program can interact with Frontier servers, or various tools written for Frontier?

              On a side note, I couldn't get WorldOutline nor Scripting2 to work yesterday. I've updated OPML Editor, and then I tried installing WorldOutline, but without success. This was done under OS X.

              On Sat, Jan 7, 2012 at 02:10, dwiner <dave.winer@...> wrote:
               

              You can get an idea of what we use Frontier for by keeping an eye on this river.

              http://river.frontiernews.org/

              Also, it is itself a Frontier application. :-)

              Dave



              --- In frontierkernel@yahoogroups.com, "ivucica" <ivucica@...> wrote:
              >
              > Hi all,
              >
              > I'm completely new to Frontier and to OPML. I'm primarily responding to Adam Curry's bat signal to help with the GNU/Linux port.
              >
              > I've done some preliminary digging around the current Frontier base and reading of this list. I don't think it can easily be salvaged and ported to GNU/Linux, at least not by an external individual new to the codebase; I don't see any way to refactor the code quickly to separate out the Windows and Mac specific code.
              >
              > Seeing the Xcode project in the source code distribution, I had high hopes that OPML Editor had at least some Cocoa code in it, and that it just interfaced with the C codebase. Unfortunately, it seems that it is completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't seem to be isolated in any way.
              >
              > I'm fully aware that I'm preaching to the choir. So here's what I propose.
              >
              > I'd love to explore writing a basic Cocoa app for writing OPML. This would mean modernized user interface under OS X. At the same time, I'd maintain the code to compile under the excellent GNUstep environment. This would mean that the same code would run under OS X and under GNU/Linux. At the same time, since GNUstep apps work under Windows and various variants of BSD, this editor would be supported on those platforms as well.
              >
              > However!
              >
              > As I said, I am completely new to Frontier and OPML. I don't know what people exactly use it for. I don't know what people's workflow is.
              >
              > I also don't want to work on separating Frontier's GUI code from Frontier's various core modules (from what I understand: scripting, database, and perhaps more). If people are willing to provide a reasonable, small set of extensible callbacks to drive the GUI code, such as "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple integration.
              >
              > When determining how we can proceed, remember that Objective-C, Python and many other languages allow dynamic instantiation of classes using names specified in strings. So there are portions that could probably be done by passing strings around when creating menu items, buttons, outline items, rather than have tight GUI integration just to do things like these.
              >
              > To determine how to proceed, and whether to proceed at all, I need feedback from Frontier users - especially Adam, since it's his call that I'm responding.
              >
              > - What do you use Frontier for?
              > - How do you use the OPML Editor?
              > - I understand that OPML Editor is tightly integrated with Frontier, can be scripted, and in fact most of its interface is Frontier-generated. How essential is this?
              > - Would it be sufficient if only a few commands were integrated?
              > - Is tight integration essential?
              > - Is WYSIWYG HTML editor integration inside the outline view essential?
              >
              > If nothing else, note that I'm willing to write a basic cross-platform OPML outliner using Objective-C language and Cocoa APIs, which means this editor would run on OS X, and on various GNUstep-supported platforms. Any postprocessing could then be done in other ways.
              >
              > Please tell me your thoughts.
              >





              --
              Ivan Vučica - ivan@...







              --
              Ivan Vučica - ivan@...


            • adamc1999
              Ivan, Post your World Outline questions to the WO Google group and I ll try to help you get it going. AC
              Message 6 of 17 , Jan 7, 2012
                Ivan,

                Post your World Outline questions to the WO Google group and I'll try to help you get it going.

                AC

                --- In frontierkernel@yahoogroups.com, Ivan Vučica <ivucica@...> wrote:
                >
                > Hi Dave!
                >
                > After receiving Adam's response, I've began work on a separate Cocoa-based
                > OPML application which'll be extremely easy to port to GNU/Linux using
                > GNUstep. I decided against porting Frontier itself to Cocoa and GNUstep,
                > since I'm too new to the platform, and the time I'll have available for
                > spending on this endeavor is probably very, very limited.
                >
                > Since less than one day of work went into it, it's still very basic. Its
                > source code is available here:
                > http://bitbucket.org/ivucica/opml
                >
                > - Is there a way to separate Frontier scripting core, including the
                > database, from the GUI?
                > - Having command-line version of Frontier that runs on any POSIX system
                > would mean one could run server portions of various tools without porting
                > the GUI. What's the situation there?
                > - Is there some documentation on how a non-Frontier program can interact
                > with Frontier servers, or various tools written for Frontier?
                >
                > On a side note, I couldn't get WorldOutline nor Scripting2 to work
                > yesterday. I've updated OPML Editor, and then I tried installing
                > WorldOutline, but without success. This was done under OS X.
                >
                > On Sat, Jan 7, 2012 at 02:10, dwiner <dave.winer@...> wrote:
                >
                > > **
                > >
                > >
                > > You can get an idea of what we use Frontier for by keeping an eye on this
                > > river.
                > >
                > > http://river.frontiernews.org/
                > >
                > > Also, it is itself a Frontier application. :-)
                > >
                > > Dave
                > >
                > >
                > > --- In frontierkernel@yahoogroups.com, "ivucica" <ivucica@> wrote:
                > > >
                > > > Hi all,
                > > >
                > > > I'm completely new to Frontier and to OPML. I'm primarily responding to
                > > Adam Curry's bat signal to help with the GNU/Linux port.
                > > >
                > > > I've done some preliminary digging around the current Frontier base and
                > > reading of this list. I don't think it can easily be salvaged and ported to
                > > GNU/Linux, at least not by an external individual new to the codebase; I
                > > don't see any way to refactor the code quickly to separate out the Windows
                > > and Mac specific code.
                > > >
                > > > Seeing the Xcode project in the source code distribution, I had high
                > > hopes that OPML Editor had at least some Cocoa code in it, and that it just
                > > interfaced with the C codebase. Unfortunately, it seems that it is
                > > completely made of legacy Carbon and Mac OS Classic code. GUI code doesn't
                > > seem to be isolated in any way.
                > > >
                > > > I'm fully aware that I'm preaching to the choir. So here's what I
                > > propose.
                > > >
                > > > I'd love to explore writing a basic Cocoa app for writing OPML. This
                > > would mean modernized user interface under OS X. At the same time, I'd
                > > maintain the code to compile under the excellent GNUstep environment. This
                > > would mean that the same code would run under OS X and under GNU/Linux. At
                > > the same time, since GNUstep apps work under Windows and various variants
                > > of BSD, this editor would be supported on those platforms as well.
                > > >
                > > > However!
                > > >
                > > > As I said, I am completely new to Frontier and OPML. I don't know what
                > > people exactly use it for. I don't know what people's workflow is.
                > > >
                > > > I also don't want to work on separating Frontier's GUI code from
                > > Frontier's various core modules (from what I understand: scripting,
                > > database, and perhaps more). If people are willing to provide a reasonable,
                > > small set of extensible callbacks to drive the GUI code, such as
                > > "FGCreateButton()", "FGCreateMenu()", et al, that would allow simple
                > > integration.
                > > >
                > > > When determining how we can proceed, remember that Objective-C, Python
                > > and many other languages allow dynamic instantiation of classes using names
                > > specified in strings. So there are portions that could probably be done by
                > > passing strings around when creating menu items, buttons, outline items,
                > > rather than have tight GUI integration just to do things like these.
                > > >
                > > > To determine how to proceed, and whether to proceed at all, I need
                > > feedback from Frontier users - especially Adam, since it's his call that
                > > I'm responding.
                > > >
                > > > - What do you use Frontier for?
                > > > - How do you use the OPML Editor?
                > > > - I understand that OPML Editor is tightly integrated with Frontier, can
                > > be scripted, and in fact most of its interface is Frontier-generated. How
                > > essential is this?
                > > > - Would it be sufficient if only a few commands were integrated?
                > > > - Is tight integration essential?
                > > > - Is WYSIWYG HTML editor integration inside the outline view essential?
                > > >
                > > > If nothing else, note that I'm willing to write a basic cross-platform
                > > OPML outliner using Objective-C language and Cocoa APIs, which means this
                > > editor would run on OS X, and on various GNUstep-supported platforms. Any
                > > postprocessing could then be done in other ways.
                > > >
                > > > Please tell me your thoughts.
                > > >
                > >
                > >
                > >
                >
                >
                >
                > --
                > Ivan Vučica - ivan@...
                >
              • dwiner
                When you say you re working on a separate Cocoa-based OPML application is that an outliner? I think Ted is right, WINE is the best approach. If we know they
                Message 7 of 17 , Jan 8, 2012
                  When you say you're working on a "separate Cocoa-based OPML application" is that an outliner?

                  I think Ted is right, WINE is the best approach. If we know they make changes that break apps, just take a snapshot and we'll test each new version of WINE and if it breaks stuff we can report bugs. If there ever is a port to Linux, imho, this is how it will be created.

                  From here-on some advice for anyone contemplating the factoring approach, now or in the future...

                  The questions about separating the engine from the UI are (sorry) fairly typical newbie questions. You'll find many threads in the archive here on that subject. Usually people give up on that project pretty quickly. Frontier's power is the integration between the components. It's not like other scripting environments that way. What you're describing the architecture of Python or PHP, not Frontier.

                  If one were to try to do this separation, and if one succeeded all you will have accomplished is reinventing Python. When you finished, in 2015 or so, you'd find the world had already moved way beyond that (the world of 2012 already has).

                  Dave
                • Douglas Frick
                  ... I may be one of the few old-school Frontier users left, but I suspect what everyone else is doing depends on the same base routines I need. I use the core
                  Message 8 of 17 , Jan 8, 2012
                    >To determine how to proceed, and whether to proceed at all, I need
                    >feedback from Frontier users - especially Adam, since it's his call
                    >that I'm responding.
                    >
                    >- What do you use Frontier for?

                    I may be one of the few old-school Frontier users left, but I suspect
                    what everyone else is doing depends on the same base routines I need.
                    I use the core features that were available in Userland Frontier 3
                    (UserTalk scripting, object database, AppleScript interface) to
                    process data feeds, write input and read output for my own faceless
                    applications, drive some 3rd party applications, and maintain state
                    for an extensive script to accomplish critical business tasks. I
                    don't use uBASE, Bertha, Manila, Radio Userland, OPML, HTML or server
                    features. Being able to quickly tweak scripts and modify tables is a
                    crucial advantage of Frontier.I can barely imagine how difficult it
                    would be to replicate my Frontier-based system with code, shell
                    scripts and SQL databases.

                    I'd like to see the Frontier Kernel updated to use Cocoa or something
                    that will ensure its survival for a third decade. If Apple does kill
                    the deprecated GUI/IO routines Frontier calls, I'd be stuck on aging
                    hardware and system software...forever.
                    --

                    Douglas Frick
                    <mailto:dfrick@...>
                    <http://www.pfr.com/dfrick/>
                  • Brent Simmons
                    Apple has already deprecated a bunch of things Frontier uses. It s impossible to build Frontier using Xcode since 4.0. It s not necessary -- at least not yet
                    Message 9 of 17 , Jan 8, 2012
                      Apple has already deprecated a bunch of things Frontier uses. It's
                      impossible to build Frontier using Xcode since 4.0.

                      It's not necessary -- at least not yet -- to switch to Cocoa. It's not a
                      bad idea, but it's a bigger job than is needed to get Frontier using
                      modern APIs instead of deprecated APIs. (Most of the job is moving from
                      QuickDraw to Quartz.)

                      -Brent

                      On Sun, Jan 08, 2012 at 10:55:50AM -0700, Douglas Frick wrote:
                      > I'd like to see the Frontier Kernel updated to use Cocoa or something
                      > that will ensure its survival for a third decade. If Apple does kill
                      > the deprecated GUI/IO routines Frontier calls, I'd be stuck on aging
                      > hardware and system software...forever.
                      > --
                      >
                      > Douglas Frick
                    • Bill Kearney
                      Shame apple doesn t have a way to run their old OSes and machines in virtual machines. It s darned handy being able to pull an aging Windows or Linux machine
                      Message 10 of 17 , Jan 9, 2012
                        Shame apple doesn't have a way to run their old OSes and machines in virtual
                        machines.

                        It's darned handy being able to pull an aging Windows or Linux machine into
                        a VM and be forever free of the old hardware. I've got at least a dozen
                        old machines safely tucked away as VMs. Ready to boot at a moment's notice
                        should need arise. No more wrangling with what does or doesn't work with
                        new OSes or patches. Saves a ton of rack/shelf space too, that and
                        dramatically lower power consumption.

                        -----Original Message-----
                        If Apple does kill the deprecated GUI/IO routines Frontier calls, I'd be
                        stuck on aging
                        hardware and system software...forever.
                      • Bill Kearney
                        Shame apple doesn t have a way to run their old OSes and machines in virtual machines. It s darned handy being able to pull an aging Windows or Linux machine
                        Message 11 of 17 , Jan 9, 2012
                          Shame apple doesn't have a way to run their old OSes and machines in virtual
                          machines.

                          It's darned handy being able to pull an aging Windows or Linux machine into
                          a VM and be forever free of the old hardware. I've got at least a dozen
                          old machines safely tucked away as VMs. Ready to boot at a moment's notice
                          should need arise. No more wrangling with what does or doesn't work with
                          new OSes or patches. Saves a ton of rack/shelf space too, that and
                          dramatically lower power consumption.

                          -----Original Message-----
                          If Apple does kill the deprecated GUI/IO routines Frontier calls, I'd be
                          stuck on aging
                          hardware and system software...forever.
                        • Douglas Frick
                          ... I have Snow Leopard Server running in VMware Fusion, and Lion can run in a VM as well, so I suppose my Frontier-based processing system could survive quite
                          Message 12 of 17 , Jan 9, 2012
                            >Shame apple doesn't have a way to run their old OSes and machines in virtual
                            >machines.
                            >
                            >-----Original Message-----
                            >If Apple does kill the deprecated GUI/IO routines Frontier calls, I'd be
                            >stuck on aging
                            >hardware and system software...forever.


                            I have Snow Leopard Server running in VMware Fusion, and Lion can run
                            in a VM as well, so I suppose my Frontier-based processing system
                            could survive quite a few more years that way. If I replaced my
                            servers with the latest hardware, it might not even run much slower.
                            I write faceless applications in portable C/C++, so I could keep
                            Xcode 3 in the VM to compile my code, since it's likely that
                            executables compiled on the 'outside' would eventually fail to work
                            inside the VM.

                            I tried it, and Frontier Kernel 10.1a15 runs just fine in the Snow
                            Leopard Server VM.

                            VMware does add another level of complexity and commercial-software
                            liability that I'd prefer to avoid. If it came down to it, I have
                            wine on my Mac, so I suppose I could try the Windows version of
                            Frontier Kernel. Thanks for reminding me. I feel better now :-)

                            Doug
                            --

                            Douglas Frick
                            <mailto:dfrick@...>
                            <http://www.pfr.com/dfrick/>
                          • Ivan Vučica
                            Hi Dave, Yes, the application is currently intended to be just an outliner, nothing else. Regarding WINE, well, that s simply not fun to me ;) And if the work
                            Message 13 of 17 , Jan 10, 2012
                              Hi Dave,

                              Yes, the application is currently intended to be just an outliner, nothing else.

                              Regarding WINE, well, that's simply not fun to me ;)
                              And if the work one does is not entertaining to him, then it doesn't make much sense to do it in the first place.

                              Regarding separating UI from the engine, I'm sorry to hear that. I really feel that model-view-controller paradigm should be followed wherever possible, and that component isolation has proven itself to be a strength, not a weakness, during the last few decades. It doesn't matter how the end user perceives the product, as long as it is internally componentized. For example, in the Frontier ecosystem, WorldOutline is not integrated into Frontier; it's running on top of Frontier.

                              If Frontier was internally structured as a bunch of systems that communicate with each other, WINE would not have to be the only solution for running under Linux, and the OS X application would not have to use outdated APIs, for the reasons of platform-specific components being too tightly integrated.

                              I think greatest thing about any platform (Frontier included) are its applications (or -- tools). I hope that there will be some work on cutting out at least the GUI part so that server portions of Frontier can be run on otherwise unsupported platforms. I surely cannot hope to accomplish that, since I have no idea what portions of code depend on other portions of code.

                              If only Frontier were written as an X11 client, it'd run on all today's major platforms. Probably on future ones, too, since an X11 display server is not a too complex piece of code, and there are already some very portable servers that can be used as starting points for whatever GUI paradigm the fate decides to bestow upon us in the next year, in the next decade or in the next century.

                              Please, definitely consider making it possible to run Frontier and its tools without GUI.

                              On Sun, Jan 8, 2012 at 18:53, dwiner <dave.winer@...> wrote:
                               

                              When you say you're working on a "separate Cocoa-based OPML application" is that an outliner?

                              I think Ted is right, WINE is the best approach. If we know they make changes that break apps, just take a snapshot and we'll test each new version of WINE and if it breaks stuff we can report bugs. If there ever is a port to Linux, imho, this is how it will be created.

                              From here-on some advice for anyone contemplating the factoring approach, now or in the future...

                              The questions about separating the engine from the UI are (sorry) fairly typical newbie questions. You'll find many threads in the archive here on that subject. Usually people give up on that project pretty quickly. Frontier's power is the integration between the components. It's not like other scripting environments that way. What you're describing the architecture of Python or PHP, not Frontier.

                              If one were to try to do this separation, and if one succeeded all you will have accomplished is reinventing Python. When you finished, in 2015 or so, you'd find the world had already moved way beyond that (the world of 2012 already has).

                              Dave




                              --
                              Ivan Vučica - ivan@...


                            Your message has been successfully submitted and would be delivered to recipients shortly.