rc5 development tasks

  • Jeff Chapman

    Jeff Chapman - 2006-01-03

    Here is a list of development tasks for the next release:

    1) Implement browser targetting for MacOS.

    2) Allow for passing in new browsers via a System Property.

    3) Extend API to pass in a list of browsers to target.

    4) Investigate feature request for closing an opened browser. I think we might be able to kill the process that started the browser.

    • cjdance

      cjdance - 2006-01-11

      Hi Jeff,

      First of all just a quick thankyou for the work done on BL2 so far.  Also thanks for integrating my suggestions/patch for Win98 and the "available browsers" method on Windows.

      Here are a few comments regarding future development.

      1) I agree with an option to add additional browsers via an API and a system property.  This would be a useful addition and would allow future flexibility.  I would however suggest that we target all major browsers "by default".  I would rather see people report a deficiency in the list of supported browsers rather than work around it by using the API or system property.  A quick look suggests that it’s almost there on Unix and the only notable exception on Windows is Opera.  Any others wish to comment?

      2) The DEFAULT browser option on *nix is implemented by checking a static list of browsers in alpha order.  It would be nice if the "default" option behaved more like Windows and used the desktop environment's default browser setting.  Implementing this would involve:

         i)    Detecting the present desktop environment (i.e. Gnome or KDE).  This could be done by looking at environment variables ???
         ii)    Extract the desktop default browser launch command.  For example, on Gnome use the command:
      gconftools –g /desktop/gnome/url-handlers/http/command'
         iii)    Match the command against BL2's available browser list.

      Care would need to be taken to ensure the results of this action are cached as there would be a fair overhead in the lookup.

      3) Similar to point 2 it would be great to have the option to target a set of browsers based on a preference list.  For example, consider the case where a developer may wish to launch at a URL that is "best viewed with Firefox", but if Firefox was not available, rather than fail, just fall back to another browser.  This could be addressed with an additional API method like:
          openURL(List browserPreference, String url)
      (Note: I know this can be done programmatically with the current API but it would be nice to have as an already implemented standard part of the API).

      4) I believe calling openUrl on Unix platforms blocks, while on other platforms it returns and opens the browser asynchronously.  For consistency I think the behaviour should be the same on all platforms.  I know the suggestion is to call openURLinBrowser in a separate thread, however maybe we should add a convenience method to do this for you?  i.e. create a daemon thread.

      5) I also have a few other general project comments:
          i) Can we put a link to the news page from the project's home page? Or maybe maintain a change log?
          ii) Maybe we could add a "quick start guide" to make it obvious how to download and use BL2? i.e. the important bits from the "General API Notes" section.



      Christopher Dance
      PaperCut Software Pty. Ltd.
      Profile: http://www.papercut.biz/company.htm#chris
      Weblog:  http://blogs.papercutsoftware.com/chris.dance/

    • Jeff Chapman

      Jeff Chapman - 2006-01-17

      Hi Chris,

      Item 1:
      Under Linux/Unix, we are targetting Mozilla, Firefox, Opera, and Konqueror. We should add Galeon (the Gnome counterpart to Konqueror).

      Windows is targetting Mozilla, Firefox, and IE. Yes, we should add Opera.

      Browser targetting is not implemented for the Mac code.

      Adding a new browser should a rare work around.

      Item 2:

      Item 3:
      Yes, providing a list of browsers is a good idea. Currently, if your preferred browser fails, the code falls through to the default.

      Item 4:
      Agreed. There is a thread class but I see no reason after reviewing the code that the thread creation and start cannot be handled behind the scenes. This will make the api easier to use and result in fewer errors. I think the thread blocks on Windows too but I'll check. It doesn't really matter though.

      Item 5:
      Yes, we definitely need a quick start guide.

      I should have some time later this week to get started on some of these items.

    • Sean Kerwick

      Sean Kerwick - 2006-01-30

      Hello Jeff,

      I'd just like to say that the work you've completed so far is astounding.  Great project!

      I'm very interested in helping out with bug scrubbing and testing fixes.  I've helped with code in SF before, VeriQuickWiki.

      I have access to a fairly large number of testing systems as well, having five configurable PC boxes at home as well as my laptop, and access to Apple machines. 

      Please let me know if I can help.


    • Roland Behrmann

      Roland Behrmann - 2006-02-09


      i just opened a feature request to mavenize this project. Additional infos can be found there.


    • Jeff Chapman

      Jeff Chapman - 2006-02-24

      Hi Roland,

      Thanks for your work. I'm not interested in using Maven for building but I am interesting in placing browserlauncher2 in the maven repository. That's something we'll pursue after the next release.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks