jEdit Community home jEdit Community Wiki > Main > ImprovingJeditLauncher (r1.1 vs. r1.46) jEdit Community Wiki webs:
Main | Plugins | Know | TWiki | Sandbox
Main . { Whats New | Users | Groups | Changes | Index | Search | Go }
 <<O>>  Difference Topic ImprovingJeditLauncher (r1.46 - 22 Jul 2004 - Martin Fischbach)
Changed:
<
<

Planned options for jedit launcher

>
>

Old options of John Gellene's jedit launcher

First, doc is available at

http://cvs.sourceforge.net/viewcvs.py/*checkout*/jedit/jeditshell/html/launcher-guide.html?rev=1.10

-h opens help screen
-p open GUI to setup JRE Directory, path to jedit.jar and startup options
-i $java_jre_dir install jedit launcher
$java_jre_dir is the dir where Java Runtime Environment resides
see http://cvs.sourceforge.net/viewcvs.py/jedit/jEdit/installer/OperatingSystem.java?rev=1.18&view=markup
-u uninstall jedit launcher

Planned options for Martin Fischbach's jedit launcher

Changed:
<
<

Possible options for jedit

>
>

Possible options for jedit


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.45 - 19 Jul 2004 - Martin Fischbach)
Added:
>
>

Planned options for jedit launcher

Added:
>
>

Possible options for jedit

Changed:
<
<

>
>

-usage  
-version  
-log=$loglevel $loglevel is an integer, setting the level of logging details
-nosettings  
-settings=$settingsdir $settingsdir is the directory where settings are saved
-noserver  
-server  
-server=$serverfile $serverfile specifies port, accesskey and version
-background  
-nobackground  
-gui  
-nogui  
-newview  
-newplainview  
-reuseview  
-restore  
-norestore  
-plugins  
-noplugins  
-startupscripts  
-nostartupscripts  
-run=$scriptfile $scriptfile is the script to run
-wait  
-quit  

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.44 - 10 Jul 2004 - Brian Hks)
Added:
>
>

Brian Hks wrote on - 10 Jul 2004

I have actually tried that. Not for this project but for another one I did in the past. Hated it. It doesn't give me the level of control I want in a make system. So I decided to write my own. It is based on bean shell. I'll post a source forge project for it in a couple of days.

Brian


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.43 - 08 Jul 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach wrote on 08 July 2004, 1:48pm

Changed:
<
<

Initial page created by

>
>

Brian, perhaps you have overseen http://ant-contrib.sourceforge.net/cc.html

Changed:
<
<

-- Martin Fischbach - 25 Jun 2004

>
>

Iīll give it a try ....

Initial page created by Martin Fischbach - 25 Jun 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.42 - 07 Jul 2004 - Brian Hks)
Changed:
<
<

Initial page created by

>
>

Added:
>
>

Brian Hks - 07 Jul 2004

This page sums up what I have found with trying to use Ant to build C++ projects http://c2.com/cgi/wiki?ApacheAnt Ant is just not designed for building non Java apps. I couldn't find a way to get Ant to loop through the source file list and compile each one to an obj file. Then there is no way to do dependency checking so if only one file is updated it will rebuild that one file only. Make does all this in a relatively compact build file.

I say stay with make.

Brian

Initial page created by


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.41 - 07 Jul 2004 - Martin Fischbach)
Changed:
<
<

-- Brian Hks - 07 Jul 2004

>
>

Brian Hks wrote on 07 Jul 2004

Added:
>
>

Martin Fischbach wrote on 07 July 2004, 11:42am

  • COM registration and eventually context menu registration is fine in Dll Register Server?(). Where to put program group creation, desktop shortcut, etc.? Install stuff neither belongs to jedit.dll nor to jedit.exe in my option .... but it is in better in jedit.exe than in jedit.dll and on the other hand, a jeditinstall.exe isnīt even better ....
  • Why do we pollute launcher with ifdefs. Installation routines go into a seperate class, one version from unix, one for windows. I donīt see the point .... f.e. take a look on how jedit does the install for different OS
  • Please post your experience with ANT


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.40 - 07 Jul 2004 - Brian Hks)
Added:
>
>

-- Brian Hks - 07 Jul 2004

This is why I do not thing the install junk belongs in the launcher. In the end there should be two binaries jedit.exe and jedit.dll. The exe is the launcher of course. jedit.dll is the COM server, now if it is done write it is a self contained program that includes install and uninstall.

Microsoft kindly provides an exe called regsvr32.exe in \winnt\system32. In the windows java install it can call "regsvr32.dll jedit.dll" regsvr32 looks in the dll for the Dll Register Server? export and calls it. In this call the dll simply needs to add its class id to the COM registry (by using registry api's) and then place its class id in the shellex key right by the one I've done in my static version. Uninstall is done by calling regsvr32 /u jedit.dll this will call Dll Unregister Server? that does the oposite of the other one.

This way we pollute jedit.exe with ifdefs for windows specific junk.

I'll look at changing my code to compile using ant, it should be better in our environment.

Brian

PS is there any way to be notified by email when this page is updated?


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.39 - 05 Jul 2004 - Martin Fischbach)
Added:
>
>

  • exact syntax specification of command line options
Added:
>
>

5. July 2004

Martin:

COM Server

  • Basic COM object working ...... need some help in registering the COM server on Win 2000/XP machines!

Jedit launcher:

  • Introduced unicode/ansi capable class for the general handling and verification of command line options - waiting for exact syntax specs

Changed:
<
<

Brian Hawkins released a completely different version of the jedit launcher smile See

>
>

Brian Hks released a completely different version of the jedit launcher smile See

Deleted:
<
<

Taaaadaaa!

Changed:
<
<

>
>

Changed:
<
<

Matthew Zaleski - 02 Jul 2004:

>
>

Matthew Zaleski wrote on 02 Jul 2004:

Added:
>
>

Martin Fischbach wrote on 05 July 2004

@Matthew:

  • free MS compiler - OK
  • ANT: somebody needs to check usability with MS compilers - TEST
  • Code Base?: The goal is to create a working launcher,
    • which is simple to use
    • whose source is easy to maintain
    • which satiesfies the community and slava smile
  • Old Launcher: I think you are wrong with what the old jedit launcher did in the register. The old launcher registered a COM server
  • Win95/98 vs. Win 2000/XP: The api s are not that different in general. On win 2000 xp you have to care the fact, that you are in a multiuser environment. TESTing is still an important issue! But still the golden rule: avoid as much MS specific code as you can wink
  • New laucher: need your help in proper COM registration

@Brian:

  • GNUmake: lets check, in how far ANT is usable!
  • COM: see current state
  • Feature set: Lets wait for Slavas post / specification
  • Install: I donīt think, that including the install routine into the jedit launcher will increase its size dramatically. If this becomes a problem, we can still seperate those install stuff and do a "jeditinstall.exe"!

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.38 - 02 Jul 2004 - Brian Hks)
Added:
>
>

Brian Hks wrote on 2 July 2004:

My reason for GNU make is that the make files then become portable. We use the windows gnu make.exe at where I work and I'm not sure where it was obtained. Probably compiled form source. I'll post the exe on my web page along with my source.

Ant would be fine with me as well. Although getting ant to compile C++ code doesn't work as well as using make. The dependancy rules make uses are awesome where as ant tends to lack in that area.

For clarification the reg file I've posted is not anything like the way the old launcher works. The old launcher would register the a COM module that would get called anytime a file was right clicked on. In that call the COM module would add the menu items to the right click window depending on what files were selected when the click occured. That is how you get the diff option when two files are selected.

I've written some COM modules and it really is not very difficult. It basically has to do two things. 1. register it's guid properly and 2. implement the correct interface for the callback from the right click.

I have to disagree with the above feature set. Install setup and config should not be part of the launcher. These are options that are better left to a seperate Java app. The reason is that all they do is manipulate the properties file. The install on the other hand is very windows specific and can be done by a batch file that calls regsvr on the COM DLL.

Brian


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.37 - 02 Jul 2004 - Matthew Zaleski)
Added:
>
>

Matthew Zaleski - 02 Jul 2004:

Good News on COM integration. Let me know if you want some help in that area.

  • I don't see a problem with the free version of Microsoft's compiler either. I read the fine print and found nothing that prevents us using it for our purposes (but I'm not a lawyer). I think as long as we pick tools everyone can get free of charge we'll be ok.
  • Although I never used ANT, I think it fits better with the jEdit development (as I assume it uses ANT for a make engine).
  • Code base: I think you left out a verb in your response. I'm guessing you meant to imply that you have no problems with bifurcating the code. If so, I disagree for something that will ship with the jEdit product. Especially since we are talking about code implementation versus feature set. All we need to do is agree on the feature set and get Slava's blessing.
  • Launcher test: Sorry, brain fart. It is the COM integration that is the tricky one for hosing a working installation. I assume that the .REG file included in the new jEdit Launchers is basically identical to what jEdit installer does prior to jEdit 4.2pre12 (which just means "replace jedit.exe with the test version").
  • I was figuring Win95 or Win98. Just be aware that, based on my experience, there are significant differences in the APIs from Win9x to W2k/Wxp. Given that COM has been such a moving target over the years, we'll need someone with access to a Win95 box to test it.

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.36 - 02 Jul 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach wrote on 02 Jul 2004:

For COM shell integration:

Meanwhile I found a good example on how to do COM object. Source should even compile under Ming W? / GCC. Extensions of that COM object towards shell capibilities are a piece of cake! Just implemententing 4 methods smile I think I can finish that stuff until Tuesday 06.07.2004! Let ya know .....

For Launcher:

I have implemented the whole variety of above mentioned command line options for my launcher, should work with unicode now, but havenīt done a test yet. I will upload the current version within the next days after tests are successfully run! Will do updates and improvements for modularisation ...

@ Matthew:

  • Hmm, I think the free MS compiler is fine ..... donīt know if Ming W? is a better choice !?!
  • Ya, at least as I know, GNU Make requires Cygwin ....... ask Brian for that ......... I donīt see the point, why we canīt use ANT instead of GNUMake or NMake for that? Comments plz!
  • Code base: donīt you which is code is better ..... everybody can choose the launcher he prefers smile
  • Launcher test: it should be no problem to extract jedit.cfg and jedit.exe, edit jedit.cfg and run jedit.exe then with the params you like smile Integration and test of COM component should be no prob either! What is your fear ... ?
  • I think Win >= 95

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.35 - 01 Jul 2004 - Matthew Zaleski)
Deleted:
<
<

Brian Hks wrote on 30 Jun 2004:

Ok I changed my mind the COM module is again an option. I got the static context registry change to work. The only thing the COM module would be needed for is to do a diff using the GUI. Opening files and multiple files can be done with the static context registry change.

My launcher pretty much does everything but the -diff (because the plugin is busted) and optional jvm switches. I've update my code on the web site listed above.

Now I need to: add the jvm switches option and port to linux.

Added:
>
>

Brian Hks wrote on 30 Jun 2004:

Ok I changed my mind the COM module is again an option. I got the static context registry change to work. The only thing the COM module would be needed for is to do a diff using the GUI. Opening files and multiple files can be done with the static context registry change.

My launcher pretty much does everything but the -diff (because the plugin is busted) and optional jvm switches. I've update my code on the web site listed above.

Now I need to: add the jvm switches option and port to linux.

Matthew Zaleski wrote on 01 Jul 2004:

Added:
>
>

I'm trying to set up my environment to match what I think everyone else involved in this project is using:

  • I just downloaded the Microsoft Visual Toolkit 2003 since that is what the link points to. Are we standardizing on the free Microsoft Compiler?
  • I don't work from the command line too often for compiling. How tied are we to Gnu Make versus any other Make utility? IIRC to get Gnu Make, I would have to load Cygwin to make it work which doesn't entice me too much.
  • Beyond the comments already stated here, are we favoring Brian's code base or Martin's codebase? I haven't compiled either one but I did browse the source code for a bit. I do agree with the comments: Brian's code is more modular, and Martin's code makes better use of C++ strings and templates. Both seemed well written at first blush.
  • I'm at a loss for how to cleanly test these Launchers short of using another computer. I'm not too keen on dorking my main development machine's current Launcher to play with the alternatives.
  • What versions of Windows are we targetting with the Launcher and COM DLL? Whenever I've dived into Microsoft API's, it's like skipping through a minefield to actually determine the least-common-denominator for available features. Do any of us HAVE older versions of Windows available to test on? I'm running Windows XP on every machine I have.

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.34 - 30 Jun 2004 - Brian Hks)
Changed:
<
<

Brian Hks wrote on 28 Jun 2004:

>
>

Brian Hks wrote on 30 Jun 2004:

Changed:
<
<

From some tests I've done with my launcher the COM module will be needed. If the static context menu item is added and you click on a file to edit the CWD is set to where you clicked on the file. This makes it hard for the launcher to read the properties file to locate the JVM and JEdit.

>
>

Ok I changed my mind the COM module is again an option. I got the static context registry change to work. The only thing the COM module would be needed for is to do a diff using the GUI. Opening files and multiple files can be done with the static context registry change.

Changed:
<
<

A bug was recently entered where international characters are not getting passed to jedit correctly. I've found a way on both Linux and Windows to get Unicode strings from the command line. This will ease converting it to UTF8 and sending it to JEdit. I've set up a test machine and I'm testing it out now.

>
>

My launcher pretty much does everything but the -diff (because the plugin is busted) and optional jvm switches. I've update my code on the web site listed above.

Now I need to: add the jvm switches option and port to linux.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.33 - 29 Jun 2004 - Martin Fischbach)
Changed:
<
<

-- Brian Hks - 28 Jun 2004

>
>

Brant Gurganus wrote on 25 Jun 2004

I was also setting up the script to do a diff and found that the diff plugin does not work on 4.2. Does any one know when this will get fixed?

The previous jEditLauncher had issues when accounts were limited accounts on Windows. To help avoid this issue, you can use Microsoft's Application Verifier program. It is free and makes sure that APIs are used correctly and the registry is accessed properly. Especially with security tightening for stuff like this in Service Pack 2, you might take a look through the Designed for Windows XP guidelines. Some of the stuff like using the Windows Installer for installation is hogwash, but it points out things to avoid for things to work in a multi-user environment.

Brian Hks wrote on 28 Jun 2004:

Changed:
<
<

I was also setting up the script to do a diff and found that the diff plugin does not work on 4.2. Does any one know when this will get fixed?

>
>

Martin Fischbach wrote on 29 Jun 2004:

Added:
>
>

Brian, seems like your wiki account is working smile Sry, I didnīt reply to your mail!

Changed:
<
<

-- Martin Fischbach - 25 Jun 2004

>
>

Ya, we need a COM module! Iīll start that probably tomorrow, as soon as Iīm finished with that commandline stuff!

Donīt know how to do it on *nix, but windows offers a main procedure with w_char *argv[]! Hope that is similar on linux!?!

How to merge both version of our launchers?

Deleted:
<
<

The previous jEditLauncher had issues when accounts were limited accounts on Windows. To help avoid this issue, you can use Microsoft's Application Verifier program. It is free and makes sure that APIs are used correctly and the registry is accessed properly. Especially with security tightening for stuff like this in Service Pack 2, you might take a look through the Designed for Windows XP guidelines. Some of the stuff like using the Windows Installer for installation is hogwash, but it points out things to avoid for things to work in a multi-user environment.

Changed:
<
<

-- Brant Gurganus - 25 Jun 2004

>
>

Initial page created by -- Martin Fischbach - 25 Jun 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.32 - 29 Jun 2004 - Brian Hks)
Changed:
<
<

>
>

Added:
>
>

-- Brian Hks - 28 Jun 2004

From some tests I've done with my launcher the COM module will be needed. If the static context menu item is added and you click on a file to edit the CWD is set to where you clicked on the file. This makes it hard for the launcher to read the properties file to locate the JVM and JEdit.

A bug was recently entered where international characters are not getting passed to jedit correctly. I've found a way on both Linux and Windows to get Unicode strings from the command line. This will ease converting it to UTF8 and sending it to JEdit. I've set up a test machine and I'm testing it out now.

I was also setting up the script to do a diff and found that the diff plugin does not work on 4.2. Does any one know when this will get fixed?


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.31 - 28 Jun 2004 - Martin Fischbach)
Added:
>
>

  • (2) -wait flag: Make the launcher wait for a reply from jEdit before it allows itself to go away. On windows there is often the problem where by the time jEdit is ready to load the file the launcher has already exited and some other process has deleted the file thinking I am done with it. This happens when launching things from zip programs, Outlook, etc.
Added:
>
>

jedit -wait causes jeditlauncher to wait, until jedit has opened buffer

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.30 - 25 Jun 2004 - Martin Fischbach)
Changed:
<
<

25.04.2004, 7am

>
>

25. June 2004, 7am

Changed:
<
<

24.04.2004, 6pm

>
>

24. June 2004, 6pm

Changed:
<
<

24.04.2004, 6am

>
>

24. June 2004, 6am

Changed:
<
<

22.04.2004

>
>

up to 22. June 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.29 - 25 Jun 2004 - Brant Gurganus)
Added:
>
>

The previous jEditLauncher had issues when accounts were limited accounts on Windows. To help avoid this issue, you can use Microsoft's Application Verifier program. It is free and makes sure that APIs are used correctly and the registry is accessed properly. Especially with security tightening for stuff like this in Service Pack 2, you might take a look through the Designed for Windows XP guidelines. Some of the stuff like using the Windows Installer for installation is hogwash, but it points out things to avoid for things to work in a multi-user environment.

-- Brant Gurganus - 25 Jun 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.28 - 25 Jun 2004 - Martin Fischbach)
Changed:
<
<

Old Discussion

>
>

TODO

Changed:
<
<

Can be found here: j Edit Launcher_Until_June 2004

>
>

Priority: 1 = highest, 5 = smallest

  • (1) union and improvement of Brians and Martins jedit launchers
    • Brians launcher
      • bad: many c-ish string manipulations. string is better in fact
      • bad: command line argument handling only supports one file
      • bad: no UTF-8 for script sending via socket, could be dangerous
      • good: pretty nice class design and platform-independence
    • Martins launcher
      • bad: all in one file
      • bad: too much windows oriented, lack in platform dependent code seperation
      • good: command line arguments handling
  • (2) COM object for context menu stuff
  • (2) registry stuff handling for registering COM object and parater storage
    • perhaps a seperate class Registry.cpp
  • (3) GUI to setup start parameters manually
  • (1) not deleted server file after crash of jedit: what to do, if jedit crashed and didīt delete its server file. Then jedit launcher thinks, jedit is running, but in fact it isnīt. Possible solution: Timeout for socket connection, if no responce start new instance of jedit!?
Added:
>
>

25.04.2004, 7am

Brian Hawkins released a completely different version of the jedit launcher smile See

http://www.activeclickweb.com/java/jedit for details.

Added:
>
>

Command line options

Variables begin with $ in this notation. "jedit $file" stand thus for "jedit AFile To Open?.txt"

jedit   start jedit if it isnīt already running
jedit [$files] start jedit and opens specified files, f.e.
"jedit A.txt b.cpp" open jedit with A.txt and b.cpp
jedit -config starts a GUI to setup start parameters.
jedit -diff $file1 $file2 run jedit with diff plugin on files $file1 and $file2
jedit -setup $PathToJavaEnvironment $JEditInstallDir let launcher know where to find java.exe and jedit.jar
call during INSTALLATION
jedit -install $what $for_whom install context menu, desktop icons
$what = "desktop_icon" or "context_menu" or "program_group"
$for_whom = "all_users" or "single_user"
jedit -java $options additional options for JVM
jedit -jedit $options additional options for jEdit

Deleted:
<
<

  • jedit.exe [files] opens all files
  • jedit.exe -config starts a GUI to setup start parameters.
  • jedit.exe -diff file1 file2
  • jedit.exe -register_context_menu and jedit.exe -unregister_context_menu
  • jedit.exe -install_program_group and jedit.exe -uninstall_program_group
  • jedit.exe -install_desktop_icon and jedit.exe -uninstall_desktop_icon
  • additional flags -for_all_users or -for_single_user
  • encapsulated flags for JVM: jedit.exe -jvm="-Mvmv=512kb"
  • encapsulated flags for jEdit: jedit.exe -jedit="-noplugins -norestore"
Deleted:
<
<

First goal should be the points in red!

Added:
>
>

Old Discussion

Can be found here: j Edit Launcher_Until_June 2004

Changed:
<
<

-- Martin Fischbach - 22 Jun 2004

>
>

-- Martin Fischbach - 25 Jun 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.27 - 25 Jun 2004 - Martin Fischbach)
Changed:
<
<

Alex Kli and Martin Fischbach and others tried to rebuild the jEditLauncher from old sources and collected new ideas. Meanwhile more people demonstrated there interest in rebuilding the jEditLauncher. The majority of people wants to drop the old sources and rebuild a slim version of the jEditLauncher, best with open source tools.

>
>

Alex Kli and Martin Fischbach and others tried to rebuild the jEditLauncher from old sources and collected new ideas. Meanwhile more people demonstrated their interest in rebuilding the jEditLauncher. The majority of people wants to drop the old sources and rebuild a slim version of the jEditLauncher, best with open source tools.

Added:
>
>

Additional information

The free microsoft c++ compiler can be obtained from

http://msdn.microsoft.com/visualc/vctoolkit2003/


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.26 - 24 Jun 2004 - Martin Fischbach)
Added:
>
>

24.04.2004, 6pm

Taaaadaaa!
Changed:
<
<

As the old version of jEditLauncher is discontinued due to unmaintainable, incomplete sources and several bugs, it is not included in further releases of jEdit anymore. Many people miss the features of the old jEditLauncher and want a replacement for the old launcher.

>
>

Iīm proud to present first alpha release of the new jedit launcher:

http://www.martin-fischbach.de/jeditlauncher/jedit_bin.zip (binary)

http://www.martin-fischbach.de/jeditlauncher/jedit_source_ms_visual_c.zip (source)

Extract achieve and read readme.txt smile

Changed:
<
<

24.04.2004

At the moment I (Martin Fischbach) am implementing the jedit.exe as described below. (using Visual C++, with as less Microsoft specific stuff as possible). Apart from registry stuff and some little missing features the new jeditlauncher is nearly finished. As soon as Iīm really finished with that Iīll post jedit.exe and source here! If anybody wants sources or wants to contribute directly please email me!
>
>

Please let me know your comments!

24.04.2004, 6am

At the moment I (Martin) am implementing the jedit.exe as described below. (using Visual C++, with as less Microsoft specific stuff as possible). Apart from registry stuff and some little missing features the new jeditlauncher is nearly finished. As soon as Iīm really finished with that Iīll post jedit.exe and source here! If anybody wants sources or wants to contribute directly please email me!
Added:
>
>

General

As the old version of jEditLauncher is discontinued due to unmaintainable, incomplete sources and several bugs, it is not included in further releases of jEdit anymore. Many people miss the features of the old jEditLauncher and want a replacement for the old launcher.

Changed:
<
<

  • jedit.exe does the main startup stuff. Either starting a new instance or doing a socket connection to a running jedit server. This should be a piece of cake .... Ming W? should be fine!
  • jedit.exe [files] opens all files
>
>

  • jedit.exe does the main startup stuff. Either starting a new instance or doing a socket connection to a running jedit server. This should be a piece of cake .... Ming W? should be fine!
  • jedit.exe [files] opens all files

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.25 - 24 Jun 2004 - Martin Fischbach)
Added:
>
>


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.24 - 24 Jun 2004 - Martin Fischbach)
Added:
>
>

24.04.2004

At the moment I (Martin Fischbach) am implementing the jedit.exe as described below. (using Visual C++, with as less Microsoft specific stuff as possible). Apart from registry stuff and some little missing features the new jeditlauncher is nearly finished. As soon as Iīm really finished with that Iīll post jedit.exe and source here! If anybody wants sources or wants to contribute directly please email me!

Brian Hawkins has had some fine ideas about the new launcher. As far as possible they are integreted on this page under category "Design". (Brian, plz fill in missing stuff! Are you implementing something at the moment?)

whorfin tries to build the launcher from a java program, which is natively compiled (no java byte code) with gcj!

22.04.2004

Added:
>
>

People contributing or who want to contribute


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.23 - 22 Jun 2004 - Martin Fischbach)
Changed:
<
<

Improving the jEditLauncher

>
>

jEditLauncher

Changed:
<
<

About jEditLauncher

>
>

What is it?

jEditLauncher is a set of tools for starting jEdit and integrating it into the shell environment of the operating systems. (Microsoft Windows currently being the most important)
Changed:
<
<

jEditLauncher is a set of tools for integrating jEdit into the Microsoft Windows operating systems.

>
>

Old Discussion

Changed:
<
<

It contains a jedit.exe, which calls the java process with commandline parameters, which are easy to configure via another config utility (e.g. switching from java to javaw or changing the memory heap). It also is aware of a running jEdit instance (the Edit Server?, which receives information via a Socket), and communicates with it if you open a file with jEdit, when it's already runing.

>
>

Can be found here: j Edit Launcher_Until_June 2004

Changed:
<
<

The best thing is a context menu handler for the explorer, so when you select a file and right-click on it, you will see the entries "Open file with jEdit" and "Open all *.xy files with jedit". If you select two files, you will even see the option to do a diff of those two files in jEdit.

>
>

Current State

Changed:
<
<

The original author (John Gellene, jgellene@nyc.rr.com) is not maintaining jEditLauncher any more. Therefore Slava wanted to drop jEditLauncher completely. But many jEdit users want this tool, and some feature requests were made. Now I (Alex Kli) started to work on that project to prevent it's death.

>
>

As the old version of jEditLauncher is discontinued due to unmaintainable, incomplete sources and several bugs, it is not included in further releases of jEdit anymore. Many people miss the features of the old jEditLauncher and want a replacement for the old launcher.

Alex Kli and Martin Fischbach and others tried to rebuild the jEditLauncher from old sources and collected new ideas. Meanwhile more people demonstrated there interest in rebuilding the jEditLauncher. The majority of people wants to drop the old sources and rebuild a slim version of the jEditLauncher, best with open source tools.

Feature wish list

  • start jEdit via console command (f.e. jedit filetoopen.txt)
  • start jEdit from within context menu * all currently selected files * all files of one type * if 2 files are selected, it is possible to start jedit with diff running
  • if jedit is running, files will be opened in new jedit views, instead of spawning a new jedit instance
  • GUI setup of start options (heap memory, etc.) for jEdit
  • registration/unregistration of context menu handler
  • possibility to pass command line switches to jEdit
  • install/uninstall (desktop) shortcuts, program group per user / per all users

Design

  • all context menu handling needs a registered COM object. Building this COM object with Ming W? seems to be a pain (author: I searched the web, but found little information about COM with Ming W?. Has somebody knowledge about that!?!), thus Visual C++ seems to be the alternative. (jEditContextMenuCOM) This COM object calls jedit.exe with according parameters.
  • jedit.exe does the main startup stuff. Either starting a new instance or doing a socket connection to a running jedit server. This should be a piece of cake .... Ming W? should be fine!
  • jedit.exe [files] opens all files
  • jedit.exe -config starts a GUI to setup start parameters.
  • jedit.exe -diff file1 file2
  • jedit.exe -register_context_menu and jedit.exe -unregister_context_menu
  • jedit.exe -install_program_group and jedit.exe -uninstall_program_group
  • jedit.exe -install_desktop_icon and jedit.exe -uninstall_desktop_icon
  • additional flags -for_all_users or -for_single_user
  • encapsulated flags for JVM: jedit.exe -jvm="-Mvmv=512kb"
  • encapsulated flags for jEdit: jedit.exe -jedit="-noplugins -norestore"
Changed:
<
<

Big Picture

jEditLauncher was coded in C++ with Visual Studio 6. There are two COM components (one for the connection with the jEdit Server) and one for the context menu handler. Both reside in DLLs. There are some exe's (jedit.exe, jinit.exe,...).

The stuff in CVS is not complete and some things are wrong. Thus I had some problems, could not compile everything and it was not much fun. But after some time, I looked into it again... so here are my results:

Analysis

Problems with the current CVS code base

Here's a detailed list of the problems:

  • the main workspace file (dsw for VC6) in cvs is wrong, but its easy to correct it; there are no project files for the projects "ltslog" (a logging DLL) and "logtest" in cvs, but the source files exist - the workspace file still includes the non-existing projects which makes Visual Studio? crash
  • you need the WTL (Windows Template Library) (some subprojects make use of the atlapp.h and atlmisc.h headers) - get it at http://www.microsoft.com/downloads/details.aspx?familyid=128e26ee-2112-4cf7-b28e-7727d9a1f288&displaylang=en
  • JELauncher.cpp(236) has a type error in a call to SetTimer (correct by changing UINT_PTR to UINT in JELauncher.h/cpp)
  • in the main directory the file JEditCtxMenu.cpp which implements the context menu handler (e.g. "Open files in jedit") is missing

If these issues are solved, everything should compile.

  • there are files in cvs which get auto-generated during the build process, so they should not resist in the repository; these are: "jeditshell.h", "jeditshell_i.c", "jeditshell_p.c" in the root directory and "jeditlauncher.h", "jeditlauncher_i.c" and "jeditlauncher_p.c" in the directory "jeditlauncher"
  • the projects "jeditinit" and "jinit" have custom build settings which copies the finished files to an install directory - this needs to be set for your local system (not really a problem)

Functionality

Having looked at the sources, I personally find it very much code for most things, and it's difficult to maintain. Maybe it would be better to reimplement it to make it simpler (hey, and we could start with Ming W?!).

The following problems with the functionality currently exist:

  • the installation does not use the registry for all users / current user settings (see my recent posts)
  • shortcuts on the desktop and the start menu are hardcoded, you cannot change what shortcuts you want to have installed and where to place them
  • you cannot decide if you want the context menu handler
  • when choosing "jedit diff" from the context menu it needs sometimes a number of retries until the already running jedit shows the diff (that's what I often experience)

Bugs can be found on http://sourceforge.net/tracker/?group_id=588&atid=100588 - set category to "installer", Status to "Any", Sort By to "Open Date" and "Descending".

Components

Here is a list of the components. Also have a look at the last documentation from John Gellene, available form viewcvs at http://cvs.sourceforge.net/viewcvs.py/*checkout*/jedit/jeditshell/html/launcher-guide.html?rev=1.10

  • Shortcuts and file installing (which is also an interesting point for people interested in plugin-bundles and settings installed with the jedit core) can be done much easier with an installer tool. I don't know which one of the open-source / freeware installer tools is the best, but someone will know.

  • The connection to jedit's Edit Server? must be done via Sockets. These features are integrated in the jEditLauncher COM component. Most of the executables call's the COM object to do the work. The only advantage of having this functionality in a COM object is that you can use it with scripting languages in the Windows environment, such as VBScript, JScript, Perl and Python. Maybe this can be changed into a simpler DLL or even a Java application, because handling Socket's in Java is easier than within C/C++.

  • The context menu handler is a COM component as well. This is the only way to implement a dynamic context handler for the windows explorer. Here are some links covering that topic:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_extending/extensionhandlers/contextmenuhandlers.asp http://www.oreilly.com/catalog/vbshell/chapter/ch04.html

  • The actual launcher (jedit.exe) and the tool to configure the java launch settings (jedinit.exe) are ok. I don't think they need to be changed.

  • The logging class (project ltslog) is small and does not necessarily have to be in a separate DLL. Logging itself should not be removed. BTW, you'll find all the logs in "%JEDIT_INSTALL_DIR%/jelaunch.log".

New Concept

Here are some ideas/requirements for a new jeditlauncher. Feel free to add your own ideas!

Basic Requirements:

  • This is important. With the current launcher you cannot use jEdit's command line switches (-norestore, -noplugins, etc.) on the jedit.exe command line. This should be supported. It might require some logic on the part of the launcher, eg if the user runs jedit -settings=someDirectory then it should look for a 'server' file in someDirectory/server.
  • Another thing is that the launcher passes file names through the edit server even for the initial instance. This is less than ideal. For the initial instance, file names should be passed on the jedit.jar command line.
  • Launcher for the jedit process: configurable java VM and appropriate command line paramters for (a) the JVM and (b) for jedit
  • For Windows 95/98/ME/NT/2000/XP
  • For nix Desktop Environments (KDE, GNOME, ...) *Don't worry about this in jEdit 4.2.
  • Double-click in shell or file-manager (depending on system) to open selected file-types with jedit
  • Context menu in shell or file-manager (depending on system) to (a) open selected file(s), (b) all files with the extension of the current selected file, (c) initiate jedit diff of 2 selected files
  • Persistent storing of settings (location of jedit, location of java vm, command-line-paramters, launcher-specific stuff)
  • Distinguish between per-user and system default settings
  • Communication with jEdit Edit Server? (via Sockets) to open files in already running instance

Technical ideas:

  • Dynamic COM Context menu handler for Windows (the only way to achieve this)
  • Some dynamic handler for KDE, GNOME, etc. as well (TODO: RESEARCH ON HOW TO IMPLEMENT THIS)
  • Settings in Windows in registry: HKEY_CURRENT_USER for per-user, HKEY_LOCAL_MACHINE for system default (subdirectory is Software/jedit.org/jedit<VERSION>)
  • Settings in nix environment: ~/.jedit/launcher for per-user, /etc/jedit/launcher for system default *On Unix, these sorts of things are usually set with environment variables defined in, for example, /etc/profile or ~/.profile.
  • (Note: the system default setting can only be set by an administrator/root, typically only them can write to HKEY_LOCAL_MACHINE or /etc)
  • Language? Modules? Same for windows and unix? Where do we need separate tools?
  • It would be nice if the jEditLauncher on Windows was built using OSS tools.
>
>

First goal should be the points in red!

Changed:
<
<

Slava Pestov

... I personally find it very much code for most things, and it's difficult to maintain ...

I agree. > 200K is too much for an .exe wrapper. On KDE or GNOME most of what jEditLauncher does can be achieved with a few small shell scripts, and some custom settings in Konqueror and Nautilus.

... can be done much easier with an installer tool ...

Well jEdit has an installer smile

... These features are integrated in the jEditLauncher COM component. [...] Maybe this can be changed into a simpler DLL ...

I think having a DLL is easier, since COM objects have to be registered, etc. I've never heard of a single instance of anyone using the jEdit Launcher? object.

Kevin Williams
I've thought about doing this, but I redefine "newbie" when it comes to C/C++.

I believe the shell integration needs to be a COM object to work ... someone correct me if I'm wrong. I also agree that the code is overkill for the task at hand. The shell integration might have some crazy requirements, but the launcher should be VERY simple. I must say that it would be nice if this were GCC-style code with a configure script and then call 'make && make install'. That way it could be build on Cygwin with Min GW? or on Linux.

Not a helpful comment, I know. smile I wish I could help more.

Slava Pestov

Alex, do you have a time frame for a release of jEditLauncher? I'd like to have an updated one ready to ship with 4.2final (which at the moment is slated for release at the end of the year).

I've added some comments to the sections above. Let me know what you think.

Martin Fischbach

Hi all!

To Slava: What is your time frame for jEdit 4.2 final? How much time would we have to reimplement/finish jEditLauncher? (slava) As long as it takes...

To Alex: I made some progress with COM components!

At the moment I still have some difficulty to understand all of the functionality the current jEditLauncher provides! Maybe you or somebody else can help, or perhaps I just didnīt get the point

  • say, we want no scripting and no context capabilities:
    • could a batch-file start jedit properly with all options possible? f.e.PATH\javaw -jar PATH\jedit.jar (slava) Batch files open ugly DOS prompts!
    • why is communication with jedit server so important? can we use -reuseview instead? [alex] we probably could. jedit has all to communicate with itself, we don't need it coded again in c++. *However, starting a JVM for the sole purpose of communicating with the jEdit server is slower than writing a jEdit client in c++*

  • say, we want a context menu: couldnīt we start an appropiate batch file from with COM component instead of communication with jEdit Server then? [alex] I am sure that might work

  • if I call jedit from within console, jedit.exe is executed. Is this right? [alex] Yes, because there is no jedit batch file for windows. Actually starting jedit needs a java call with jedit.jar as jar paramter (java -jar jedit.jar) How is the jedit "command" done for nix environments? [alex] With a short shell script.

Alex Kli

To Martin: I answered some of your questions above in bold font.

You are right, probably everything could be handled by a batch file which passes the command line arguments to jEdit's main class (sth. like: "java.bat XYZ" => "C:\Java\java.exe -jar jedit.jar XYZ").

The thing is we need something that controls the actually used Java Runtime Environment (a certain java.exe) and makes this configurable (so that the user can chose it). We can now argue or vote, if we need that or if this should happen explicitly by the PATH environment variable (in my opinion we could kick this if we have a good batch file).

The other thing I really want is the context menu because I do use it. There we do need a simple COM component.

John Watson

To: Alex, Martin

I did some preliminary work in this direction (script files). You can download it at http://flagrantdisregard.com/jeditlaunch.zip

I've been using this setup for a couple of days now and find it acceptable for daily use. Also, adding items to the context menu doesn't have to require a COM component if you are willing to individually setup file associations in Windows, which is a simple registry hack. A front-end could be written, again in script, that could allow the user to choose the file associations and make the registry entries for him (it could even create Start menu items and shortcuts and let the user choose a run-time and options). The Windows Scripting host, included with Windows, has all of this functionality.

Btw, the latest versions of the run-time put javaw.exe on the path and create a file association for .jar files so all a user has to do to launch jedit is double-click jedit.jar (or type jedit.jar in a console if the jedit folder is also on the path).

Alex Kli

To John: But you cannot instantiate a shell context menu handler without a COM component. The point is that this works for any filetypes. The diff functionality is also only possible with a dynamic context menu handler.

Installing functionality could indeed moved to a script. But some people have turned off the Windows Scripting Host due to its security issues - you cannot rely on that.

Slava Pestov

A batch file or a script is not sufficient. You need a jEdit client written in C++. Spawning a JVM to communicate with the jEdit server wastes time; a native client is one of the advantages of jEditLauncher. Also batch files force DOS windows to be opened.

Alex Kli

To Slava: But on *nix you launch jedit and thus a new VM to pass commands to an exisiting Java instance. Is this really a problem?

There is a command called "start.exe" in Windows which works like doing a "command &" and a "disown" after that in a Bash shell. E.g. "start java -jar jedit.jar %0 %1 %2 %3 %4 %5 %6 %7 %8 %9" will start the jedit process and the batch file from which this start command was issued will exit and close its window.

Martin Fischbach

To Alex: Start.exe works fine! Can one somehow prevent the flashing dos window?

To Slava: I donīt see the problem with a new VM either? Do you think the startup time would increase dramatically?

Apart from that Iīll try to setup a simple COM component for jEdit with Ming W?. I will let you know soon about the results!

Martin Fischbach

Checked the internet for Ming W? sources for an example COM component ... I didnīt find anything useful! frown Maybe someone else has experience with COM and gcc or g++ or mingw !?

Apart from that, is there a change to contact John Gellene for the missing JEditCtxMenu.cpp ???

Alex Kli

I haven't tried Ming W? yet... But shouldn't it work if you take a Microsoft example (see the link above about writing COM context menu handlers) and pass it through the Ming W? compiler? Maybe I am a bit naiv...

I tried to contact John Gellene several times, he must have received all the mails from jedit-users and jedit-devel but he never responded. Don't consider this as an option. Anyway, as the Microsoft example shows, writing such an handler isn't very difficult (I just did not have any time for that).

Martin Fischbach

  • Found GCC sources for COM component! Should work with Ming W?.

My ideas:

  • one COM object (say jedit_menu.dll) for context menu with:
    • full context-menu handling (open with, open .xxx, diff, run script)
    • ability to run jedit.exe
  • one EXE? (say jedit.exe) for launching jedit or opening files in running jedit instance. IMHO we could also use a batch file for that.
    • communication with jedit server
  • one EXE? (say jedit_install.exe) for the setup of startmenu entries and context-handler registration. Iīm not sure in how far we could use a typical windows installer (Open Source Null Soft? Installer f.e.) for that or if it can be done from within jedit installer?

Questions:

  • Is there any documentation about the communication protocol between a client and the jedit server? Yes, in Edit Server?.java.
  • Should we provide a GUI for setting up options (java vs. javaw, memory, ...)
  • Installer (see above)
  • per user / per system settings to be done (alex, your ideas!)

Let me know your comments!

John Whorfin

Hello, I'm the person who chimed in on jedit-devel about helping out with coding the launcher (or perhaps even a rewrite of it). I think the ideas about going in the direction of Ming W? are spot on, maybe adding something like Wx Windows? for GUI. Or if we wanted to do something even more radical, we could try using gcj (the GNU Java-to-native code compiler). It's made great strides with GUI support over the last year or so from what I've read.

As far as the COM code goes, if we absolutely have to do it for shell integration, then we have to, but I'd really like to exhaust all the possibilites before being forced to use it. That kind of stuff winds up being a hairball more than anything else, and was the kind of thing I disliked the most about being a Windows coder.

John Whorfin

OK, a brief update:

I've been exchanging email with Brian on the launcher, and he came up with a really simple registry widget to avoid us needing a big COM hairball DLL to do right click integration. I've also started experimenting with gcj, to do compiles of Java down to a native Windows EXE. I think it should be possible to do a first cut of something that comes up, and tries to contact a running instance of JEdit with the file to be loaded. If JEdit isn't already up, it just launches it. The very first cuts would not have a pretty GUI front end for setting the launch parms. These would likely be picked up from a text file that could be edited. Eventually, a UI for configuration would be added.

The reader should be forewarned that the first revs of this will be beefy. For simplicity, I've been doing static links of the gcj executable, and a "Hello, world" weighs in at 2 MB. This can be slimmed down, of course, and even at this weight, should provide a useful proof of concept and provide grist for the discussion mill.

So, anybody who's interested, please speak up here or on the mailing list.

Martin Fischbach

Hi John,

You just want an ".exe" for starting up jedit. Thatīs fine I think and agrees with the ideas we had.

Is your idea to use to an .exe compiled java program for that?

How to build a context menu without a COM object! Details plz! Maybe I missed something ....

Grtnx

>
>

Please post your comments here!

Changed:
<
<

Martin


>
>

-- Martin Fischbach - 22 Jun 2004

Deleted:
<
<

-- Alex Kli - 03 Mar 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.22 - 19 Jun 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach

Hi John,

You just want an ".exe" for starting up jedit. Thatīs fine I think and agrees with the ideas we had.

Is your idea to use to an .exe compiled java program for that?

How to build a context menu without a COM object! Details plz! Maybe I missed something ....

Grtnx

Martin


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.21 - 15 Jun 2004 - John Whorfin)
Added:
>
>

John Whorfin

OK, a brief update:

I've been exchanging email with Brian on the launcher, and he came up with a really simple registry widget to avoid us needing a big COM hairball DLL to do right click integration. I've also started experimenting with gcj, to do compiles of Java down to a native Windows EXE. I think it should be possible to do a first cut of something that comes up, and tries to contact a running instance of JEdit with the file to be loaded. If JEdit isn't already up, it just launches it. The very first cuts would not have a pretty GUI front end for setting the launch parms. These would likely be picked up from a text file that could be edited. Eventually, a UI for configuration would be added.

The reader should be forewarned that the first revs of this will be beefy. For simplicity, I've been doing static links of the gcj executable, and a "Hello, world" weighs in at 2 MB. This can be slimmed down, of course, and even at this weight, should provide a useful proof of concept and provide grist for the discussion mill.

So, anybody who's interested, please speak up here or on the mailing list.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.20 - 05 Jun 2004 - John Whorfin)
Added:
>
>

John Whorfin

Hello, I'm the person who chimed in on jedit-devel about helping out with coding the launcher (or perhaps even a rewrite of it). I think the ideas about going in the direction of Ming W? are spot on, maybe adding something like Wx Windows? for GUI. Or if we wanted to do something even more radical, we could try using gcj (the GNU Java-to-native code compiler). It's made great strides with GUI support over the last year or so from what I've read.

As far as the COM code goes, if we absolutely have to do it for shell integration, then we have to, but I'd really like to exhaust all the possibilites before being forced to use it. That kind of stuff winds up being a hairball more than anything else, and was the kind of thing I disliked the most about being a Windows coder.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.19 - 17 Mar 2004 - Slava Pestov)
Changed:
<
<

  • Is there any documentation about the communication protocol between a client and the jedit server?
>
>

  • Is there any documentation about the communication protocol between a client and the jedit server? Yes, in Edit Server?.java.

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.18 - 08 Mar 2004 - Martin Fischbach)
Changed:
<
<

    • full context-menu handling
>
>

    • full context-menu handling (open with, open .xxx, diff, run script)
Added:
>
>

    • communication with jedit server
  • one EXE? (say jedit_install.exe) for the setup of startmenu entries and context-handler registration. Iīm not sure in how far we could use a typical windows installer (Open Source Null Soft? Installer f.e.) for that or if it can be done from within jedit installer?
Changed:
<
<

  • Is there any documentation about the communication protocol between a client and jedit server?
>
>

  • Is there any documentation about the communication protocol between a client and the jedit server?
Added:
>
>

  • Installer (see above)
  • per user / per system settings to be done (alex, your ideas!)

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.17 - 08 Mar 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach

  • Found GCC sources for COM component! Should work with Ming W?.

My ideas:

  • one COM object (say jedit_menu.dll) for context menu with:
    • full context-menu handling
    • ability to run jedit.exe
  • one EXE? (say jedit.exe) for launching jedit or opening files in running jedit instance. IMHO we could also use a batch file for that.

Questions:

  • Is there any documentation about the communication protocol between a client and jedit server?
  • Should we provide a GUI for setting up options (java vs. javaw, memory, ...)

Let me know your comments!


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.16 - 03 Mar 2004 - Alex Kli)
Added:
>
>

Alex Kli

I haven't tried Ming W? yet... But shouldn't it work if you take a Microsoft example (see the link above about writing COM context menu handlers) and pass it through the Ming W? compiler? Maybe I am a bit naiv...

I tried to contact John Gellene several times, he must have received all the mails from jedit-users and jedit-devel but he never responded. Don't consider this as an option. Anyway, as the Microsoft example shows, writing such an handler isn't very difficult (I just did not have any time for that).

Changed:
<
<

-- Alex Kli - 26 Feb 2004

>
>

-- Alex Kli - 03 Mar 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.15 - 03 Mar 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach

Checked the internet for Ming W? sources for an example COM component ... I didnīt find anything useful! frown Maybe someone else has experience with COM and gcc or g++ or mingw !?

Apart from that, is there a change to contact John Gellene for the missing JEditCtxMenu.cpp ???


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.14 - 26 Feb 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach

To Alex: Start.exe works fine! Can one somehow prevent the flashing dos window?

To Slava: I donīt see the problem with a new VM either? Do you think the startup time would increase dramatically?

Apart from that Iīll try to setup a simple COM component for jEdit with Ming W?. I will let you know soon about the results!


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.13 - 26 Feb 2004 - Alex Kli)
Changed:
<
<

Slava Pestov

>
>

Slava Pestov

Added:
>
>

Alex Kli

To Slava: But on *nix you launch jedit and thus a new VM to pass commands to an exisiting Java instance. Is this really a problem?

There is a command called "start.exe" in Windows which works like doing a "command &" and a "disown" after that in a Bash shell. E.g. "start java -jar jedit.jar %0 %1 %2 %3 %4 %5 %6 %7 %8 %9" will start the jedit process and the batch file from which this start command was issued will exit and close its window.

Changed:
<
<

-- Alex Kli - 25 Feb 2004

>
>

-- Alex Kli - 26 Feb 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.12 - 26 Feb 2004 - Slava Pestov)
Changed:
<
<

To Slava: What is your time frame for jEdit 4.2 final? How much time would we have to reimplement/finish jEditLauncher?

>
>

To Slava: What is your time frame for jEdit 4.2 final? How much time would we have to reimplement/finish jEditLauncher? (slava) As long as it takes...

Changed:
<
<

    • could a batch-file start jedit properly with all options possible? f.e.PATH\javaw -jar PATH\jedit.jar
    • why is communication with jedit server so important? can we use -reuseview instead? [alex] we probably could. jedit has all to communicate with itself, we don't need it coded again in c++.
>
>

    • could a batch-file start jedit properly with all options possible? f.e.PATH\javaw -jar PATH\jedit.jar (slava) Batch files open ugly DOS prompts!
    • why is communication with jedit server so important? can we use -reuseview instead? [alex] we probably could. jedit has all to communicate with itself, we don't need it coded again in c++. *However, starting a JVM for the sole purpose of communicating with the jEdit server is slower than writing a jEdit client in c++*
Added:
>
>

Slava Pestov

A batch file or a script is not sufficient. You need a jEdit client written in C++. Spawning a JVM to communicate with the jEdit server wastes time; a native client is one of the advantages of jEditLauncher. Also batch files force DOS windows to be opened.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.11 - 25 Feb 2004 - Alex Kli)
Added:
>
>

Alex Kli

To John: But you cannot instantiate a shell context menu handler without a COM component. The point is that this works for any filetypes. The diff functionality is also only possible with a dynamic context menu handler.

Installing functionality could indeed moved to a script. But some people have turned off the Windows Scripting Host due to its security issues - you cannot rely on that.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.10 - 25 Feb 2004 - John Watson)
Added:
>
>

John Watson

To: Alex, Martin

I did some preliminary work in this direction (script files). You can download it at http://flagrantdisregard.com/jeditlaunch.zip

I've been using this setup for a couple of days now and find it acceptable for daily use. Also, adding items to the context menu doesn't have to require a COM component if you are willing to individually setup file associations in Windows, which is a simple registry hack. A front-end could be written, again in script, that could allow the user to choose the file associations and make the registry entries for him (it could even create Start menu items and shortcuts and let the user choose a run-time and options). The Windows Scripting host, included with Windows, has all of this functionality.

Btw, the latest versions of the run-time put javaw.exe on the path and create a file association for .jar files so all a user has to do to launch jedit is double-click jedit.jar (or type jedit.jar in a console if the jedit folder is also on the path).


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.9 - 25 Feb 2004 - Alex Kli)
Changed:
<
<

    • why is communication with jedit server so important? can we use -reuseview instead?
>
>

    • why is communication with jedit server so important? can we use -reuseview instead? [alex] we probably could. jedit has all to communicate with itself, we don't need it coded again in c++.
Changed:
<
<

  • say, we want a context menu: couldnīt we start an appropiate batch file from with COM component instead of communication with jEdit Server then?
>
>

  • say, we want a context menu: couldnīt we start an appropiate batch file from with COM component instead of communication with jEdit Server then? [alex] I am sure that might work

  • if I call jedit from within console, jedit.exe is executed. Is this right? [alex] Yes, because there is no jedit batch file for windows. Actually starting jedit needs a java call with jedit.jar as jar paramter (java -jar jedit.jar) How is the jedit "command" done for nix environments? [alex] With a short shell script.

Alex Kli

To Martin: I answered some of your questions above in bold font.

You are right, probably everything could be handled by a batch file which passes the command line arguments to jEdit's main class (sth. like: "java.bat XYZ" => "C:\Java\java.exe -jar jedit.jar XYZ").

The thing is we need something that controls the actually used Java Runtime Environment (a certain java.exe) and makes this configurable (so that the user can chose it). We can now argue or vote, if we need that or if this should happen explicitly by the PATH environment variable (in my opinion we could kick this if we have a good batch file).

The other thing I really want is the context menu because I do use it. There we do need a simple COM component.

Deleted:
<
<

  • if I call jedit from within console, jedit.exe is executed. Is this right? How is the jedit "command" done for nix environments?
Changed:
<
<

-- Alex Kli - 19 Oct 2003

>
>

-- Alex Kli - 25 Feb 2004


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.8 - 25 Feb 2004 - Martin Fischbach)
Added:
>
>

Martin Fischbach

Hi all!

To Slava: What is your time frame for jEdit 4.2 final? How much time would we have to reimplement/finish jEditLauncher?

To Alex: I made some progress with COM components!

At the moment I still have some difficulty to understand all of the functionality the current jEditLauncher provides! Maybe you or somebody else can help, or perhaps I just didnīt get the point

  • say, we want no scripting and no context capabilities:
    • could a batch-file start jedit properly with all options possible? f.e.PATH\javaw -jar PATH\jedit.jar
    • why is communication with jedit server so important? can we use -reuseview instead?

  • say, we want a context menu: couldnīt we start an appropiate batch file from with COM component instead of communication with jEdit Server then?

  • if I call jedit from within console, jedit.exe is executed. Is this right? How is the jedit "command" done for nix environments?

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.7 - 22 Feb 2004 - Alex Kli)
Added:
>
>

Bugs can be found on http://sourceforge.net/tracker/?group_id=588&atid=100588 - set category to "installer", Status to "Any", Sort By to "Open Date" and "Descending".


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.6 - 29 Oct 2003 - Slava Pestov)
Added:
>
>

  • This is important. With the current launcher you cannot use jEdit's command line switches (-norestore, -noplugins, etc.) on the jedit.exe command line. This should be supported. It might require some logic on the part of the launcher, eg if the user runs jedit -settings=someDirectory then it should look for a 'server' file in someDirectory/server.
  • Another thing is that the launcher passes file names through the edit server even for the initial instance. This is less than ideal. For the initial instance, file names should be passed on the jedit.jar command line.
Changed:
<
<

  • For *nix Desktop Environments (KDE, GNOME, ...)
>
>

  • For nix Desktop Environments (KDE, GNOME, ...) *Don't worry about this in jEdit 4.2.
Changed:
<
<

  • Settings in *nix environment: ~/.jedit/launcher for per-user, /etc/jedit/launcher for system default
>
>

  • Settings in nix environment: ~/.jedit/launcher for per-user, /etc/jedit/launcher for system default *On Unix, these sorts of things are usually set with environment variables defined in, for example, /etc/profile or ~/.profile.
Added:
>
>

  • It would be nice if the jEditLauncher on Windows was built using OSS tools.
Added:
>
>

Slava Pestov

Alex, do you have a time frame for a release of jEditLauncher? I'd like to have an updated one ready to ship with 4.2final (which at the moment is slated for release at the end of the year).

I've added some comments to the sections above. Let me know what you think.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.5 - 29 Oct 2003 - Alex Kli)
Added:
>
>

New Concept

Here are some ideas/requirements for a new jeditlauncher. Feel free to add your own ideas!

Basic Requirements:

  • Launcher for the jedit process: configurable java VM and appropriate command line paramters for (a) the JVM and (b) for jedit
  • For Windows 95/98/ME/NT/2000/XP
  • For *nix Desktop Environments (KDE, GNOME, ...)
  • Double-click in shell or file-manager (depending on system) to open selected file-types with jedit
  • Context menu in shell or file-manager (depending on system) to (a) open selected file(s), (b) all files with the extension of the current selected file, (c) initiate jedit diff of 2 selected files
  • Persistent storing of settings (location of jedit, location of java vm, command-line-paramters, launcher-specific stuff)
  • Distinguish between per-user and system default settings
  • Communication with jEdit Edit Server? (via Sockets) to open files in already running instance

Technical ideas:

  • Dynamic COM Context menu handler for Windows (the only way to achieve this)
  • Some dynamic handler for KDE, GNOME, etc. as well (TODO: RESEARCH ON HOW TO IMPLEMENT THIS)
  • Settings in Windows in registry: HKEY_CURRENT_USER for per-user, HKEY_LOCAL_MACHINE for system default (subdirectory is Software/jedit.org/jedit<VERSION>)
  • Settings in *nix environment: ~/.jedit/launcher for per-user, /etc/jedit/launcher for system default
  • (Note: the system default setting can only be set by an administrator/root, typically only them can write to HKEY_LOCAL_MACHINE or /etc)
  • Language? Modules? Same for windows and unix? Where do we need separate tools?

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.4 - 26 Oct 2003 - Alex Kli)
Changed:
<
<

  • you need the ATL/WTL stuff included in modern Platform SDKs (some subprojects make use of the atlapp.h and atlmisc.h headers)
>
>

Deleted:
<
<

I have to wait until next week to receive the Platform SDK to work on compiling.

Changed:
<
<

  • The context menu handler is a COM component as well. This is the only way to implement a dynamic context handler for the windows explorer.
>
>

  • The context menu handler is a COM component as well. This is the only way to implement a dynamic context handler for the windows explorer. Here are some links covering that topic:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_int/shell_int_extending/extensionhandlers/contextmenuhandlers.asp http://www.oreilly.com/catalog/vbshell/chapter/ch04.html

 <<O>>  Difference Topic ImprovingJeditLauncher (r1.3 - 22 Oct 2003 - Kevin Williams)
Added:
>
>

Kevin Williams
I've thought about doing this, but I redefine "newbie" when it comes to C/C++.

I believe the shell integration needs to be a COM object to work ... someone correct me if I'm wrong. I also agree that the code is overkill for the task at hand. The shell integration might have some crazy requirements, but the launcher should be VERY simple. I must say that it would be nice if this were GCC-style code with a configure script and then call 'make && make install'. That way it could be build on Cygwin with Min GW? or on Linux.

Not a helpful comment, I know. smile I wish I could help more.


 <<O>>  Difference Topic ImprovingJeditLauncher (r1.2 - 19 Oct 2003 - Alex Kli)
Changed:
<
<

  • The connection to jedit's Edit Server? must be done via Sockets. These features are integrated in the jEditLauncher COM component. Most of the executables call's the COM object to do the work. The only advantage of having this functionality in a COM object is that you can use it with scripting languages in the Windows environment, such as VBScript, JScript, Perl and Python. Maybe this can be changed into a simpler DLL or even Java, because handling Socket's in Java is easier than within C/C++.
>
>

  • The connection to jedit's Edit Server? must be done via Sockets. These features are integrated in the jEditLauncher COM component. Most of the executables call's the COM object to do the work. The only advantage of having this functionality in a COM object is that you can use it with scripting languages in the Windows environment, such as VBScript, JScript, Perl and Python. Maybe this can be changed into a simpler DLL or even a Java application, because handling Socket's in Java is easier than within C/C++.
Changed:
<
<

  • The logging class (project ltslog) is small and does not necessarily have to be in a separate DLL. Logging itself should not be removed. BTW, you'll find all the logs in "/jelaunch.log".
>
>

  • The logging class (project ltslog) is small and does not necessarily have to be in a separate DLL. Logging itself should not be removed. BTW, you'll find all the logs in "%JEDIT_INSTALL_DIR%/jelaunch.log".
Changed:
<
<

None so far.

>
>

Slava Pestov

... I personally find it very much code for most things, and it's difficult to maintain ...

I agree. > 200K is too much for an .exe wrapper. On KDE or GNOME most of what jEditLauncher does can be achieved with a few small shell scripts, and some custom settings in Konqueror and Nautilus.

... can be done much easier with an installer tool ...

Well jEdit has an installer smile

... These features are integrated in the jEditLauncher COM component. [...] Maybe this can be changed into a simpler DLL ...

I think having a DLL is easier, since COM objects have to be registered, etc. I've never heard of a single instance of anyone using the jEdit Launcher? object.



 <<O>>  Difference Topic ImprovingJeditLauncher (r1.1 - 19 Oct 2003 - Alex Kli)
Added:
>
>

%META:TOPICINFO{author="AlexKli" date="1066586124" format="1.0" version="1.1"}% %META:TOPICPARENT{name="AlexKli"}%

Improving the jEditLauncher

About jEditLauncher

jEditLauncher is a set of tools for integrating jEdit into the Microsoft Windows operating systems.

It contains a jedit.exe, which calls the java process with commandline parameters, which are easy to configure via another config utility (e.g. switching from java to javaw or changing the memory heap). It also is aware of a running jEdit instance (the Edit Server?, which receives information via a Socket), and communicates with it if you open a file with jEdit, when it's already runing.

The best thing is a context menu handler for the explorer, so when you select a file and right-click on it, you will see the entries "Open file with jEdit" and "Open all *.xy files with jedit". If you select two files, you will even see the option to do a diff of those two files in jEdit.

The original author (John Gellene, jgellene@nyc.rr.com) is not maintaining jEditLauncher any more. Therefore Slava wanted to drop jEditLauncher completely. But many jEdit users want this tool, and some feature requests were made. Now I (Alex Kli) started to work on that project to prevent it's death.

Big Picture

jEditLauncher was coded in C++ with Visual Studio 6. There are two COM components (one for the connection with the jEdit Server) and one for the context menu handler. Both reside in DLLs. There are some exe's (jedit.exe, jinit.exe,...).

The stuff in CVS is not complete and some things are wrong. Thus I had some problems, could not compile everything and it was not much fun. But after some time, I looked into it again... so here are my results:

Analysis

Problems with the current CVS code base

Here's a detailed list of the problems:

  • the main workspace file (dsw for VC6) in cvs is wrong, but its easy to correct it; there are no project files for the projects "ltslog" (a logging DLL) and "logtest" in cvs, but the source files exist - the workspace file still includes the non-existing projects which makes Visual Studio? crash
  • you need the ATL/WTL stuff included in modern Platform SDKs (some subprojects make use of the atlapp.h and atlmisc.h headers)
  • JELauncher.cpp(236) has a type error in a call to SetTimer (correct by changing UINT_PTR to UINT in JELauncher.h/cpp)
  • in the main directory the file JEditCtxMenu.cpp which implements the context menu handler (e.g. "Open files in jedit") is missing

If these issues are solved, everything should compile.

  • there are files in cvs which get auto-generated during the build process, so they should not resist in the repository; these are: "jeditshell.h", "jeditshell_i.c", "jeditshell_p.c" in the root directory and "jeditlauncher.h", "jeditlauncher_i.c" and "jeditlauncher_p.c" in the directory "jeditlauncher"
  • the projects "jeditinit" and "jinit" have custom build settings which copies the finished files to an install directory - this needs to be set for your local system (not really a problem)

I have to wait until next week to receive the Platform SDK to work on compiling.

Functionality

Having looked at the sources, I personally find it very much code for most things, and it's difficult to maintain. Maybe it would be better to reimplement it to make it simpler (hey, and we could start with Ming W?!).

The following problems with the functionality currently exist:

  • the installation does not use the registry for all users / current user settings (see my recent posts)
  • shortcuts on the desktop and the start menu are hardcoded, you cannot change what shortcuts you want to have installed and where to place them
  • you cannot decide if you want the context menu handler
  • when choosing "jedit diff" from the context menu it needs sometimes a number of retries until the already running jedit shows the diff (that's what I often experience)

Components

Here is a list of the components. Also have a look at the last documentation from John Gellene, available form viewcvs at http://cvs.sourceforge.net/viewcvs.py/*checkout*/jedit/jeditshell/html/launcher-guide.html?rev=1.10

  • Shortcuts and file installing (which is also an interesting point for people interested in plugin-bundles and settings installed with the jedit core) can be done much easier with an installer tool. I don't know which one of the open-source / freeware installer tools is the best, but someone will know.

  • The connection to jedit's Edit Server? must be done via Sockets. These features are integrated in the jEditLauncher COM component. Most of the executables call's the COM object to do the work. The only advantage of having this functionality in a COM object is that you can use it with scripting languages in the Windows environment, such as VBScript, JScript, Perl and Python. Maybe this can be changed into a simpler DLL or even Java, because handling Socket's in Java is easier than within C/C++.

  • The context menu handler is a COM component as well. This is the only way to implement a dynamic context handler for the windows explorer.

  • The actual launcher (jedit.exe) and the tool to configure the java launch settings (jedinit.exe) are ok. I don't think they need to be changed.

  • The logging class (project ltslog) is small and does not necessarily have to be in a separate DLL. Logging itself should not be removed. BTW, you'll find all the logs in "/jelaunch.log".

Comments

None so far.

-- Alex Kli - 19 Oct 2003


Topic ImprovingJeditLauncher . { View | Diffs | r1.46 | > | r1.45 | > | r1.44 | More }
Revision r1.1 - 19 Oct 2003 - 17:55 GMT - Alex Kli
Revision r1.46 - 22 Jul 2004 - 09:49 GMT - Martin Fischbach
Copyright © 1999-2011 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding jEdit Community Wiki? Send feedback.
Get jEdit at !SourceForge.net. Fast, secure and Free Open Source software downloads