jEdit Community Wiki > Main > TWiki Users > Alex Kli > ImprovingJeditLauncher	jEdit Community Wiki webs: Main | Plugins | Know | TWiki | Sandbox
	Main . { Whats New | Users | Groups | Changes | Index | Search | Go }

jEditLauncher

• jEditLauncher
  • What is it?
  • TODO
  • Current State
    • 5. July 2004
    • 25. June 2004, 7am
    • 24. June 2004, 6pm
    • 24. June 2004, 6am
    • up to 22. June 2004
    • General
  • People contributing or who want to contribute
  • Feature wish list
  • Command line options
    • Old options of John Gellene's jedit launcher
    • Planned options for Martin Fischbach's jedit launcher
    • Possible options for jedit
  • Design
  • Additional information
  • Old Discussion
  • Comments

What is it?

TODO

Priority: 1 = highest, 5 = smallest

• exact syntax specification of command line options
• (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!?
• (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.

Current State

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

25. June 2004, 7am

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

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

24. June 2004, 6pm

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

Please let me know your comments!

24. June 2004, 6am

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!

up to 22. June 2004

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.

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.

People contributing or who want to contribute

• Martin Fischbach mail@martin-fischbach.de
• Alex Kli Klimetschek@t-online.de
• Brian Hks http://www.activeclickweb.com/email.php
• whorfin jedit-devel@whorfin.com
• Matthew Zaleski (M.E.) mzaleski@ford.com
• Rick Reumann r@reumann.net

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

Command line options

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

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

Planned options for Martin Fischbach's jedit launcher

Possible options for jedit

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!

Additional information

The free microsoft c++ compiler can be obtained from

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

Old Discussion

Can be found here: j Edit Launcher_Until_June 2004

Comments

Please post your comments here!

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.

Martin Fischbach wrote on 29 Jun 2004:

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

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?

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:

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.

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 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
• 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 Integration and test of COM component should be no prob either! What is your fear ... ?
• I think Win >= 95

Matthew Zaleski wrote on 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.

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

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
• 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
• 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"!

Brian Hks wrote on 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?

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

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

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

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

I´ll give it a try ....

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

Initial page created by Martin Fischbach - 25 Jun 2004