Menu
▾
▴
jedit-users
|
From: John S. <leg...@gm...> - 2011-03-23 20:28:18
|
Hi: I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. However, when I launch it, a second icon appears, and the original one I pinned is in "running" mode. I've noticed this for many other java apps, such as Eclipse or Netbeans. Does anyone know how I might fix this? If this requires programmatic changes, could someone tell me how jedit.exe works (i.e., how does it launch the java program), so I might fix it? Cheers, user |
|
From: Vampire <Va...@jE...> - 2011-03-23 21:51:38
|
Hi John, jedit.exe is a Launch4J generated executable that forks a new process in which it starts javaw.exe. The C code looks more or less like: CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, &pi)) WaitForSingleObject(pi.hProcess, INFINITE); GetExitCodeProcess(pi.hProcess, &dwExitCode); CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return dwExitCode; Better would be a call via JNI for which also a patch for Launch4J exists but it is not accepted and rather outdated now. But I don't think this has any relevance to your "problem". If you have chosen "Start jEdit Server automatically on system startup" on installation time, then if you startup Windows, jEdit is also started but without GUI and is running in the background, ready to quickly show the GUI if you need it to. I guess you have chosen this and you can verify this by looking in the last line of the About... dialog where it then says "background mode". If this is the case as I suppose, then running jEdit again will actually connect to the running jEdit instance and tell it what you want to do instead of starting jEdit again. Because of this I guess you have the described behaviour. You could disable the automatic startup of the jEdit server on system startup to change this behaviour, but then you have to wait longer for jEdit to start up as it has to start completely and not show only the GUI. For temporary tryout of the different behaviour you can also quit jEdit completely. If you use the upper right X to close the jEdit windows, you only close the GUI if jEdit is running in background mode and the jEdit server stays running. If you choose Quit from the File menu, then jEdit is completely quit and I guess the behaviour of your pinned item changes. Regards Vampire John Smith schrieb: > Hi: > > I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. > However, when I launch it, a second icon appears, and the original one > I pinned is in "running" mode. I've noticed this for many other java > apps, such as Eclipse or Netbeans. Does anyone know how I might fix > this? If this requires programmatic changes, could someone tell me > how jedit.exe works (i.e., how does it launch the java program), so I > might fix it? > > Cheers, > user > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar |
|
From: John S. <leg...@gm...> - 2011-03-24 01:17:35
|
Thanks. However, I don't think it's a jEdit server issue (I'm pretty confident I disabled the server from automatically starting), as it's a Java issue. I see the same behaviour for other Java apps. Where/how can I grab the source code for jedit.exe? I would like to play around with it to see if I can eliminate this issue. On 23 March 2011 17:50, Vampire <Va...@je...> wrote: > Hi John, > > jedit.exe is a Launch4J generated executable that forks a new process in > which it starts javaw.exe. > The C code looks more or less like: > > CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, > &pi)) > WaitForSingleObject(pi.hProcess, INFINITE); > GetExitCodeProcess(pi.hProcess, &dwExitCode); > CloseHandle(pi.hThread); > CloseHandle(pi.hProcess); > return dwExitCode; > > Better would be a call via JNI for which also a patch for Launch4J exists > but it is not accepted and rather outdated now. > > But I don't think this has any relevance to your "problem". > > If you have chosen "Start jEdit Server automatically on system startup" on > installation time, then if you startup Windows, jEdit is also started but > without GUI and is running in the background, ready to quickly show the GUI > if you need it to. I guess you have chosen this and you can verify this by > looking in the last line of the About... dialog where it then says > "background mode". If this is the case as I suppose, then running jEdit > again will actually connect to the running jEdit instance and tell it what > you want to do instead of starting jEdit again. Because of this I guess you > have the described behaviour. You could disable the automatic startup of the > jEdit server on system startup to change this behaviour, but then you have > to wait longer for jEdit to start up as it has to start completely and not > show only the GUI. For temporary tryout of the different behaviour you can > also quit jEdit completely. If you use the upper right X to close the jEdit > windows, you only close the GUI if jEdit is running in background mode and > the jEdit server stays running. If you choose Quit from the File menu, then > jEdit is completely quit and I guess the behaviour of your pinned item > changes. > > Regards > Vampire > > > John Smith schrieb: > > Hi: > > I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. > However, when I launch it, a second icon appears, and the original one I > pinned is in "running" mode. I've noticed this for many other java apps, > such as Eclipse or Netbeans. Does anyone know how I might fix this? If > this requires programmatic changes, could someone tell me how jedit.exe > works (i.e., how does it launch the java program), so I might fix it? > > Cheers, > user > > ------------------------------ > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > |
|
From: Vampire <Va...@jE...> - 2011-03-24 01:39:59
|
Hi John, other Java apps also do similar things to prevent multiple startups of the app. As I said, the jedit.exe is Launch4J generated. You find the sourcecode in the Launch4J project at http://launch4j.sourceforge.net/. In the jEdit source you can find the corresponding configuration file at http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup Regards Vampire John Smith schrieb: > Thanks. However, I don't think it's a jEdit server issue (I'm pretty > confident I disabled the server from automatically starting), as it's > a Java issue. I see the same behaviour for other Java apps. > > Where/how can I grab the source code for jedit.exe? I would like to > play around with it to see if I can eliminate this issue. > > On 23 March 2011 17:50, Vampire <Va...@je... > <mailto:Va...@je...>> wrote: > > Hi John, > > jedit.exe is a Launch4J generated executable that forks a new > process in which it starts javaw.exe. > The C code looks more or less like: > > CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, > NULL, &si, &pi)) > WaitForSingleObject(pi.hProcess, INFINITE); > GetExitCodeProcess(pi.hProcess, &dwExitCode); > CloseHandle(pi.hThread); > CloseHandle(pi.hProcess); > return dwExitCode; > > Better would be a call via JNI for which also a patch for Launch4J > exists but it is not accepted and rather outdated now. > > But I don't think this has any relevance to your "problem". > > If you have chosen "Start jEdit Server automatically on system > startup" on installation time, then if you startup Windows, jEdit > is also started but without GUI and is running in the background, > ready to quickly show the GUI if you need it to. I guess you have > chosen this and you can verify this by looking in the last line of > the About... dialog where it then says "background mode". If this > is the case as I suppose, then running jEdit again will actually > connect to the running jEdit instance and tell it what you want to > do instead of starting jEdit again. Because of this I guess you > have the described behaviour. You could disable the automatic > startup of the jEdit server on system startup to change this > behaviour, but then you have to wait longer for jEdit to start up > as it has to start completely and not show only the GUI. For > temporary tryout of the different behaviour you can also quit > jEdit completely. If you use the upper right X to close the jEdit > windows, you only close the GUI if jEdit is running in background > mode and the jEdit server stays running. If you choose Quit from > the File menu, then jEdit is completely quit and I guess the > behaviour of your pinned item changes. > > Regards > Vampire > > > John Smith schrieb: >> Hi: >> >> I am using Windows 7 64-bit, and I've pinned jedit to the >> taskbar. However, when I launch it, a second icon appears, and >> the original one I pinned is in "running" mode. I've noticed >> this for many other java apps, such as Eclipse or Netbeans. Does >> anyone know how I might fix this? If this requires programmatic >> changes, could someone tell me how jedit.exe works (i.e., how >> does it launch the java program), so I might fix it? >> >> Cheers, >> user >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar |
|
From: John S. <leg...@gm...> - 2011-03-24 20:17:28
|
Thanks. After looking at Launch4j, I don't think the fix is there. Reading around, it seems like jEdit might not be setting its Application User Model ID (AppUserModelID). So what is happening is that I have jedit.exe pinned to the taskbar, but when I launch it Windows 7 thinks the actual program is javaw.exe. I referred to the following links for my information: http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx http://stackoverflow.com/questions/1907735/using-jna-to-get-set-application-identifier Is it acceptable for me to modify jEdit to explicitly sets it's Model ID on windows 7? This would of course be OS-specific. On 23 March 2011 21:39, Vampire <Va...@je...> wrote: > Hi John, > > other Java apps also do similar things to prevent multiple startups of the > app. > As I said, the jedit.exe is Launch4J generated. You find the sourcecode in > the Launch4J project at http://launch4j.sourceforge.net/. > In the jEdit source you can find the corresponding configuration file at > http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup > > > Regards > Vampire > > John Smith schrieb: > > Thanks. However, I don't think it's a jEdit server issue (I'm pretty > confident I disabled the server from automatically starting), as it's a Java > issue. I see the same behaviour for other Java apps. > > Where/how can I grab the source code for jedit.exe? I would like to play > around with it to see if I can eliminate this issue. > > On 23 March 2011 17:50, Vampire <Va...@je...> wrote: > >> Hi John, >> >> jedit.exe is a Launch4J generated executable that forks a new process in >> which it starts javaw.exe. >> The C code looks more or less like: >> >> CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, >> &pi)) >> WaitForSingleObject(pi.hProcess, INFINITE); >> GetExitCodeProcess(pi.hProcess, &dwExitCode); >> CloseHandle(pi.hThread); >> CloseHandle(pi.hProcess); >> return dwExitCode; >> >> Better would be a call via JNI for which also a patch for Launch4J exists >> but it is not accepted and rather outdated now. >> >> But I don't think this has any relevance to your "problem". >> >> If you have chosen "Start jEdit Server automatically on system startup" on >> installation time, then if you startup Windows, jEdit is also started but >> without GUI and is running in the background, ready to quickly show the GUI >> if you need it to. I guess you have chosen this and you can verify this by >> looking in the last line of the About... dialog where it then says >> "background mode". If this is the case as I suppose, then running jEdit >> again will actually connect to the running jEdit instance and tell it what >> you want to do instead of starting jEdit again. Because of this I guess you >> have the described behaviour. You could disable the automatic startup of the >> jEdit server on system startup to change this behaviour, but then you have >> to wait longer for jEdit to start up as it has to start completely and not >> show only the GUI. For temporary tryout of the different behaviour you can >> also quit jEdit completely. If you use the upper right X to close the jEdit >> windows, you only close the GUI if jEdit is running in background mode and >> the jEdit server stays running. If you choose Quit from the File menu, then >> jEdit is completely quit and I guess the behaviour of your pinned item >> changes. >> >> Regards >> Vampire >> >> >> John Smith schrieb: >> >> Hi: >> >> I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. >> However, when I launch it, a second icon appears, and the original one I >> pinned is in "running" mode. I've noticed this for many other java apps, >> such as Eclipse or Netbeans. Does anyone know how I might fix this? If >> this requires programmatic changes, could someone tell me how jedit.exe >> works (i.e., how does it launch the java program), so I might fix it? >> >> Cheers, >> user >> >> ------------------------------ >> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar >> >> > ------------------------------ > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > |
|
From: Alan E. <ala...@gm...> - 2011-03-24 21:25:35
|
I run jEdit from the command line sometimes too, using "javaw" and other times I run jedit.exe. it would be nice if the ID was the same no matter how I started it. 2011/3/24 John Smith <leg...@gm...>: > Thanks. After looking at Launch4j, I don't think the fix is there. Reading > around, it seems like jEdit might not be setting its Application User Model > ID (AppUserModelID). So what is happening is that I have jedit.exe pinned > to the taskbar, but when I launch it Windows 7 thinks the actual program is > javaw.exe. > > I referred to the following links for my information: > > http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx > http://stackoverflow.com/questions/1907735/using-jna-to-get-set-application-identifier > > Is it acceptable for me to modify jEdit to explicitly sets it's Model ID on > windows 7? This would of course be OS-specific. > > On 23 March 2011 21:39, Vampire <Va...@je...> wrote: >> >> Hi John, >> >> other Java apps also do similar things to prevent multiple startups of the >> app. >> As I said, the jedit.exe is Launch4J generated. You find the sourcecode in >> the Launch4J project at http://launch4j.sourceforge.net/. >> In the jEdit source you can find the corresponding configuration file at >> http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup >> >> Regards >> Vampire >> >> John Smith schrieb: >> >> Thanks. However, I don't think it's a jEdit server issue (I'm pretty >> confident I disabled the server from automatically starting), as it's a Java >> issue. I see the same behaviour for other Java apps. >> >> Where/how can I grab the source code for jedit.exe? I would like to play >> around with it to see if I can eliminate this issue. >> >> On 23 March 2011 17:50, Vampire <Va...@je...> wrote: >>> >>> Hi John, >>> >>> jedit.exe is a Launch4J generated executable that forks a new process in >>> which it starts javaw.exe. >>> The C code looks more or less like: >>> >>> CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, >>> &pi)) >>> WaitForSingleObject(pi.hProcess, INFINITE); >>> GetExitCodeProcess(pi.hProcess, &dwExitCode); >>> CloseHandle(pi.hThread); >>> CloseHandle(pi.hProcess); >>> return dwExitCode; >>> >>> Better would be a call via JNI for which also a patch for Launch4J exists >>> but it is not accepted and rather outdated now. >>> >>> But I don't think this has any relevance to your "problem". >>> >>> If you have chosen "Start jEdit Server automatically on system startup" >>> on installation time, then if you startup Windows, jEdit is also started but >>> without GUI and is running in the background, ready to quickly show the GUI >>> if you need it to. I guess you have chosen this and you can verify this by >>> looking in the last line of the About... dialog where it then says >>> "background mode". If this is the case as I suppose, then running jEdit >>> again will actually connect to the running jEdit instance and tell it what >>> you want to do instead of starting jEdit again. Because of this I guess you >>> have the described behaviour. You could disable the automatic startup of the >>> jEdit server on system startup to change this behaviour, but then you have >>> to wait longer for jEdit to start up as it has to start completely and not >>> show only the GUI. For temporary tryout of the different behaviour you can >>> also quit jEdit completely. If you use the upper right X to close the jEdit >>> windows, you only close the GUI if jEdit is running in background mode and >>> the jEdit server stays running. If you choose Quit from the File menu, then >>> jEdit is completely quit and I guess the behaviour of your pinned item >>> changes. >>> >>> Regards >>> Vampire >>> >>> >>> John Smith schrieb: >>> >>> Hi: >>> >>> I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. >>> However, when I launch it, a second icon appears, and the original one I >>> pinned is in "running" mode. I've noticed this for many other java apps, >>> such as Eclipse or Netbeans. Does anyone know how I might fix this? If >>> this requires programmatic changes, could someone tell me how jedit.exe >>> works (i.e., how does it launch the java program), so I might fix it? >>> >>> Cheers, >>> user >>> >>> ________________________________ >>> >>> ------------------------------------------------------------------------------ >>> Enable your software for Intel(R) Active Management Technology to meet >>> the >>> growing manageability and security demands of your customers. Businesses >>> are taking advantage of Intel(R) vPro (TM) technology - will your >>> software >>> be a part of the solution? Download the Intel(R) Manageability Checker >>> today! http://p.sf.net/sfu/intel-dev2devmar >> >> ________________________________ >> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
|
From: Vampire <Va...@jE...> - 2011-03-24 21:57:59
|
@Alan The installer should add the jEdit program directory to the PATH variable, so you should be able to use "jedit" from the commandline and you can give it any parameter jEdit supports, it will pass it on to the javaw process. @John jEdit is under GPL, you can modify it however you like to suit your needs. And if you made it in a clean way that doesn't break anything else, you could also submit it as patch to the jEdit patches tracker if you want. Alan Ezust schrieb: > I run jEdit from the command line sometimes too, using "javaw" and > other times I run jedit.exe. > it would be nice if the ID was the same no matter how I started it. > > > 2011/3/24 John Smith <leg...@gm...>: > >> Thanks. After looking at Launch4j, I don't think the fix is there. Reading >> around, it seems like jEdit might not be setting its Application User Model >> ID (AppUserModelID). So what is happening is that I have jedit.exe pinned >> to the taskbar, but when I launch it Windows 7 thinks the actual program is >> javaw.exe. >> >> I referred to the following links for my information: >> >> http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx >> http://stackoverflow.com/questions/1907735/using-jna-to-get-set-application-identifier >> >> Is it acceptable for me to modify jEdit to explicitly sets it's Model ID on >> windows 7? This would of course be OS-specific. >> >> On 23 March 2011 21:39, Vampire <Va...@je...> wrote: >> >>> Hi John, >>> >>> other Java apps also do similar things to prevent multiple startups of the >>> app. >>> As I said, the jedit.exe is Launch4J generated. You find the sourcecode in >>> the Launch4J project at http://launch4j.sourceforge.net/. >>> In the jEdit source you can find the corresponding configuration file at >>> http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup >>> >>> Regards >>> Vampire >>> >>> John Smith schrieb: >>> >>> Thanks. However, I don't think it's a jEdit server issue (I'm pretty >>> confident I disabled the server from automatically starting), as it's a Java >>> issue. I see the same behaviour for other Java apps. >>> >>> Where/how can I grab the source code for jedit.exe? I would like to play >>> around with it to see if I can eliminate this issue. >>> >>> On 23 March 2011 17:50, Vampire <Va...@je...> wrote: >>> >>>> Hi John, >>>> >>>> jedit.exe is a Launch4J generated executable that forks a new process in >>>> which it starts javaw.exe. >>>> The C code looks more or less like: >>>> >>>> CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, >>>> &pi)) >>>> WaitForSingleObject(pi.hProcess, INFINITE); >>>> GetExitCodeProcess(pi.hProcess, &dwExitCode); >>>> CloseHandle(pi.hThread); >>>> CloseHandle(pi.hProcess); >>>> return dwExitCode; >>>> >>>> Better would be a call via JNI for which also a patch for Launch4J exists >>>> but it is not accepted and rather outdated now. >>>> >>>> But I don't think this has any relevance to your "problem". >>>> >>>> If you have chosen "Start jEdit Server automatically on system startup" >>>> on installation time, then if you startup Windows, jEdit is also started but >>>> without GUI and is running in the background, ready to quickly show the GUI >>>> if you need it to. I guess you have chosen this and you can verify this by >>>> looking in the last line of the About... dialog where it then says >>>> "background mode". If this is the case as I suppose, then running jEdit >>>> again will actually connect to the running jEdit instance and tell it what >>>> you want to do instead of starting jEdit again. Because of this I guess you >>>> have the described behaviour. You could disable the automatic startup of the >>>> jEdit server on system startup to change this behaviour, but then you have >>>> to wait longer for jEdit to start up as it has to start completely and not >>>> show only the GUI. For temporary tryout of the different behaviour you can >>>> also quit jEdit completely. If you use the upper right X to close the jEdit >>>> windows, you only close the GUI if jEdit is running in background mode and >>>> the jEdit server stays running. If you choose Quit from the File menu, then >>>> jEdit is completely quit and I guess the behaviour of your pinned item >>>> changes. >>>> >>>> Regards >>>> Vampire >>>> >>>> >>>> John Smith schrieb: >>>> >>>> Hi: >>>> >>>> I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. >>>> However, when I launch it, a second icon appears, and the original one I >>>> pinned is in "running" mode. I've noticed this for many other java apps, >>>> such as Eclipse or Netbeans. Does anyone know how I might fix this? If >>>> this requires programmatic changes, could someone tell me how jedit.exe >>>> works (i.e., how does it launch the java program), so I might fix it? >>>> >>>> Cheers, >>>> user >>>> >>>> ________________________________ >>>> >>>> ------------------------------------------------------------------------------ >>>> Enable your software for Intel(R) Active Management Technology to meet >>>> the >>>> growing manageability and security demands of your customers. Businesses >>>> are taking advantage of Intel(R) vPro (TM) technology - will your >>>> software >>>> be a part of the solution? Download the Intel(R) Manageability Checker >>>> today! http://p.sf.net/sfu/intel-dev2devmar >>>> >>> ________________________________ >>> >>> ------------------------------------------------------------------------------ >>> Enable your software for Intel(R) Active Management Technology to meet the >>> growing manageability and security demands of your customers. Businesses >>> are taking advantage of Intel(R) vPro (TM) technology - will your software >>> be a part of the solution? Download the Intel(R) Manageability Checker >>> today! http://p.sf.net/sfu/intel-dev2devmar >>> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> >> |
|
From: David A. <Dav...@EU...> - 2011-03-25 09:29:22
|
Hi John Just wanted to say that I have noticed the same issue on Windows 7. I will be grateful if you find a fix and can submit it to the community. Best regards David From: John Smith [mailto:leg...@gm...] Sent: 24 March 2011 20:17 To: Vampire Cc: jed...@li... Subject: Re: [ jEdit-users ] Pinning jEdit Properly to Windows 7 taskbar Thanks. After looking at Launch4j, I don't think the fix is there. Reading around, it seems like jEdit might not be setting its Application User Model ID (AppUserModelID). So what is happening is that I have jedit.exe pinned to the taskbar, but when I launch it Windows 7 thinks the actual program is javaw.exe. I referred to the following links for my information: http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx http://stackoverflow.com/questions/1907735/using-jna-to-get-set-application-identifier Is it acceptable for me to modify jEdit to explicitly sets it's Model ID on windows 7? This would of course be OS-specific. On 23 March 2011 21:39, Vampire <Va...@je...<mailto:Va...@je...>> wrote: Hi John, other Java apps also do similar things to prevent multiple startups of the app. As I said, the jedit.exe is Launch4J generated. You find the sourcecode in the Launch4J project at http://launch4j.sourceforge.net/. In the jEdit source you can find the corresponding configuration file at http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup Regards Vampire John Smith schrieb: Thanks. However, I don't think it's a jEdit server issue (I'm pretty confident I disabled the server from automatically starting), as it's a Java issue. I see the same behaviour for other Java apps. Where/how can I grab the source code for jedit.exe? I would like to play around with it to see if I can eliminate this issue. On 23 March 2011 17:50, Vampire <Va...@je...<mailto:Va...@je...>> wrote: Hi John, jedit.exe is a Launch4J generated executable that forks a new process in which it starts javaw.exe. The C code looks more or less like: CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, &pi)) WaitForSingleObject(pi.hProcess, INFINITE); GetExitCodeProcess(pi.hProcess, &dwExitCode); CloseHandle(pi.hThread); CloseHandle(pi.hProcess); return dwExitCode; Better would be a call via JNI for which also a patch for Launch4J exists but it is not accepted and rather outdated now. But I don't think this has any relevance to your "problem". If you have chosen "Start jEdit Server automatically on system startup" on installation time, then if you startup Windows, jEdit is also started but without GUI and is running in the background, ready to quickly show the GUI if you need it to. I guess you have chosen this and you can verify this by looking in the last line of the About... dialog where it then says "background mode". If this is the case as I suppose, then running jEdit again will actually connect to the running jEdit instance and tell it what you want to do instead of starting jEdit again. Because of this I guess you have the described behaviour. You could disable the automatic startup of the jEdit server on system startup to change this behaviour, but then you have to wait longer for jEdit to start up as it has to start completely and not show only the GUI. For temporary tryout of the different behaviour you can also quit jEdit completely. If you use the upper right X to close the jEdit windows, you only close the GUI if jEdit is running in background mode and the jEdit server stays running. If you choose Quit from the File menu, then jEdit is completely quit and I guess the behaviour of your pinned item changes. Regards Vampire John Smith schrieb: Hi: I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. However, when I launch it, a second icon appears, and the original one I pinned is in "running" mode. I've noticed this for many other java apps, such as Eclipse or Netbeans. Does anyone know how I might fix this? If this requires programmatic changes, could someone tell me how jedit.exe works (i.e., how does it launch the java program), so I might fix it? Cheers, user ________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar Click here<https://www.mailcontrol.com/sr/MXBw34iZT0jTndxI!oX7UlK7uOqmL!e8HBaV+grS8Ao2W!63kphRsGhAxR1rAUSRcG6kDahySulhjvXYAQ53ow==> to report this email as spam. |
|
From: John S. <leg...@gm...> - 2011-03-30 16:39:13
|
An update on my progress. I started by trying to set the AppID of jEdit, and finally got it to set without freezing during startup :) Unfortunately, this wasn't enough, as it appears I also need Launch4j to set the resulting executable's AppID to be the same thing. At this point I discovered a different program called WinRun4J (Vampire - you commented on that issue in Launch4J) which does work!! There isn't a nice config GUI for it like Launch4J, but the resulting executable it creates can be properly pinned. I think the difference is that WinRun4J doesn't launch javaw.exe in a separate process - perhaps it runs javaw.exe inside the same process? One final snag is that I can't seem to properly set the icon - I can only change the icon which appears in the taskbar, but the icon of the executable in Windows Explorer remains unchanged, as well as the icon in the context-menu when you right-click on the taskbar. I'm looking into the code, and trying to contact the author. On 25 March 2011 04:39, David Aldrich <Dav...@eu...> wrote: > Hi John > > > > Just wanted to say that I have noticed the same issue on Windows 7. I will > be grateful if you find a fix and can submit it to the community. > > > > Best regards > > > > David > > > > * * > > *From:* John Smith [mailto:leg...@gm...] > *Sent:* 24 March 2011 20:17 > *To:* Vampire > *Cc:* jed...@li... > *Subject:* Re: [ jEdit-users ] Pinning jEdit Properly to Windows 7 taskbar > > > > Thanks. After looking at Launch4j, I don't think the fix is there. > Reading around, it seems like jEdit might not be setting its Application > User Model ID (AppUserModelID). So what is happening is that I have > jedit.exe pinned to the taskbar, but when I launch it Windows 7 thinks the > actual program is javaw.exe. > > I referred to the following links for my information: > > http://msdn.microsoft.com/en-us/library/dd378459%28VS.85%29.aspx > > http://stackoverflow.com/questions/1907735/using-jna-to-get-set-application-identifier > > Is it acceptable for me to modify jEdit to explicitly sets it's Model ID on > windows 7? This would of course be OS-specific. > > On 23 March 2011 21:39, Vampire <Va...@je...> wrote: > > Hi John, > > other Java apps also do similar things to prevent multiple startups of the > app. > As I said, the jedit.exe is Launch4J generated. You find the sourcecode in > the Launch4J project at http://launch4j.sourceforge.net/. > In the jEdit source you can find the corresponding configuration file at > http://jedit.svn.sourceforge.net/viewvc/jedit/jEdit/trunk/package-files/windows/jedit.launch4j.xml?view=markup > > > > Regards > Vampire > > John Smith schrieb: > > Thanks. However, I don't think it's a jEdit server issue (I'm pretty > confident I disabled the server from automatically starting), as it's a Java > issue. I see the same behaviour for other Java apps. > > Where/how can I grab the source code for jedit.exe? I would like to play > around with it to see if I can eliminate this issue. > > On 23 March 2011 17:50, Vampire <Va...@je...> wrote: > > Hi John, > > jedit.exe is a Launch4J generated executable that forks a new process in > which it starts javaw.exe. > The C code looks more or less like: > > CreateProcess(NULL, cmdline, NULL, NULL, TRUE, priority, NULL, NULL, &si, > &pi)) > WaitForSingleObject(pi.hProcess, INFINITE); > GetExitCodeProcess(pi.hProcess, &dwExitCode); > CloseHandle(pi.hThread); > CloseHandle(pi.hProcess); > return dwExitCode; > > Better would be a call via JNI for which also a patch for Launch4J exists > but it is not accepted and rather outdated now. > > But I don't think this has any relevance to your "problem". > > If you have chosen "Start jEdit Server automatically on system startup" on > installation time, then if you startup Windows, jEdit is also started but > without GUI and is running in the background, ready to quickly show the GUI > if you need it to. I guess you have chosen this and you can verify this by > looking in the last line of the About... dialog where it then says > "background mode". If this is the case as I suppose, then running jEdit > again will actually connect to the running jEdit instance and tell it what > you want to do instead of starting jEdit again. Because of this I guess you > have the described behaviour. You could disable the automatic startup of the > jEdit server on system startup to change this behaviour, but then you have > to wait longer for jEdit to start up as it has to start completely and not > show only the GUI. For temporary tryout of the different behaviour you can > also quit jEdit completely. If you use the upper right X to close the jEdit > windows, you only close the GUI if jEdit is running in background mode and > the jEdit server stays running. If you choose Quit from the File menu, then > jEdit is completely quit and I guess the behaviour of your pinned item > changes. > > Regards > Vampire > > > John Smith schrieb: > > Hi: > > I am using Windows 7 64-bit, and I've pinned jedit to the taskbar. > However, when I launch it, a second icon appears, and the original one I > pinned is in "running" mode. I've noticed this for many other java apps, > such as Eclipse or Netbeans. Does anyone know how I might fix this? If > this requires programmatic changes, could someone tell me how jedit.exe > works (i.e., how does it launch the java program), so I might fix it? > > Cheers, > user > > ------------------------------ > > > > ------------------------------------------------------------------------------ > > Enable your software for Intel(R) Active Management Technology to meet the > > growing manageability and security demands of your customers. Businesses > > are taking advantage of Intel(R) vPro (TM) technology - will your software > > be a part of the solution? Download the Intel(R) Manageability Checker > > today! http://p.sf.net/sfu/intel-dev2devmar > > > > ------------------------------ > > > > ------------------------------------------------------------------------------ > > Enable your software for Intel(R) Active Management Technology to meet the > > growing manageability and security demands of your customers. Businesses > > are taking advantage of Intel(R) vPro (TM) technology - will your software > > be a part of the solution? Download the Intel(R) Manageability Checker > > today! http://p.sf.net/sfu/intel-dev2devmar > > > > Click here<https://www.mailcontrol.com/sr/MXBw34iZT0jTndxI%21oX7UlK7uOqmL%21e8HBaV+grS8Ao2W%2163kphRsGhAxR1rAUSRcG6kDahySulhjvXYAQ53ow==>to report this email as spam. > |
|
From: Rowan C. <row...@gm...> - 2011-04-18 20:58:23
|
Hi Vampire, Just wondering on what basis you have decided the project is not "stable": is it just because it has a version number less than 1.0? Given the large number of posts on this mailing list about correct versioning schemes, I'm surprised you don't realise that version numbers mean different things to different people - and in particular, /hackers are scared of 1.0/ <http://rwec.co.uk/blog/2010/02/golden-rules-of-version-naming/> I don't know anything about the project in question, but looking at their website, I see that there have been 24 releases over 4 years <http://sourceforge.net/projects/winrun4j/files/winrun4j/> (unless I'm much mistaken, 2007-05-07is not "more than 5 years" ago...) I see no summary or FAQ to tell me how stable they consider their latest release, so wouldn't want to jump to conclusions. Maybe I'm being harsh, and you have actually looked into this, but since you admitted not looking into features, it seemed like "0.4.1 < 1.0.0" was the only evidence used to condemn its inclusion. Regards, Rowan Collins [IMSoP] On 09/04/2011 01:11, Vampire wrote: > The problem is not about any features. > I didn't look into the features, maybe there is a problem too. > But the problem is that WinRun4J has not released any stable version > yet since they exist over the last couple of years. > jEdit in contrast is a pretty stable program. > If jEdit now uses and depends on WinRun4J, then jEdit itself is not to > be considered stable anymore. > You know, a chain is only as strong as its weakest link > > John Smith schrieb: >> Hi: >> >> I'm not sure I understand the concern - if it does what is needed, >> then isn't that good enough? Or is there some required feature that >> is present in Launch4J? If so, I can look into making some changes >> to it. >> >> I admit that 5 years is a long time, and perhaps it's a dead project, >> but it seems like jEdit only needs a very basic launcher. >> >> >> On 8 April 2011 09:17, Vampire <Va...@je... >> <mailto:Va...@je...>> wrote: >> >> Hi John, >> >> unfortunately it isn't. >> I was aware of WinRun4J alread. >> But they are at version 0.4.2 which means they didn't get it managed >> to release even one version they think theirselves is stable in >> more than 5 years. >> If you want to use that EXE for yourself, your free to do so of >> course. >> But I don't think we will incorporate it into the standard >> distribution. >> >> >> Regards >> Vampire >> >> John Smith schrieb: >>> I haven't heard anything for a few days - is my solution acceptable? >> [Snipped] |
|
From: Vampire <Va...@jE...> - 2011-06-13 21:51:16
|
Ok, I've spend some days now to actually evaluate WinRun4j. Of course I like the possibility to "correctly" pin jEdit to the taskbar, meaning not having a different icon for a running instance, and the process being named jedit.exe. But actually it doesn't work really smooth. It cannot be put into the build process properly as it must be assembled on a 64bit Windows system to also assemble the 64bit executables that are necessary for 64bit JVMs with WinRun4J. It also doesn't reliably start the program in question. In my tests the jEdit GUI was garbage most of the time. Also the executable attributes like version, name and description cannot be set correctly and thus in file assignment dialogs and so on jEdit is not shown nicely. The embedded icons are not shown reliably and this has nothing to do with any caches as I moved and copied around the files to circumvent eventual caches, ... All in all I have to say that WinRun4J is a nice idea, but currently too crappy for me using it in production environment. Regards Vampire 2011/4/18 Rowan Collins <row...@gm...>: > Hi Vampire, > > Just wondering on what basis you have decided the project is not "stable": > is it just because it has a version number less than 1.0? > > Given the large number of posts on this mailing list about correct > versioning schemes, I'm surprised you don't realise that version numbers > mean different things to different people - and in particular, hackers are > scared of 1.0 > > I don't know anything about the project in question, but looking at their > website, I see that there have been 24 releases over 4 years (unless I'm > much mistaken, 2007-05-07 is not "more than 5 years" ago...) I see no > summary or FAQ to tell me how stable they consider their latest release, so > wouldn't want to jump to conclusions. > > Maybe I'm being harsh, and you have actually looked into this, but since you > admitted not looking into features, it seemed like "0.4.1 < 1.0.0" was the > only evidence used to condemn its inclusion. > > Regards, > Rowan Collins > [IMSoP] > > > > On 09/04/2011 01:11, Vampire wrote: > > The problem is not about any features. > I didn't look into the features, maybe there is a problem too. > But the problem is that WinRun4J has not released any stable version yet > since they exist over the last couple of years. > jEdit in contrast is a pretty stable program. > If jEdit now uses and depends on WinRun4J, then jEdit itself is not to be > considered stable anymore. > You know, a chain is only as strong as its weakest link > > John Smith schrieb: > > Hi: > > I'm not sure I understand the concern - if it does what is needed, then > isn't that good enough? Or is there some required feature that is present > in Launch4J? If so, I can look into making some changes to it. > > I admit that 5 years is a long time, and perhaps it's a dead project, but it > seems like jEdit only needs a very basic launcher. > > > On 8 April 2011 09:17, Vampire <Va...@je...> wrote: >> >> Hi John, >> >> unfortunately it isn't. >> I was aware of WinRun4J alread. >> But they are at version 0.4.2 which means they didn't get it managed >> to release even one version they think theirselves is stable in more than >> 5 years. >> If you want to use that EXE for yourself, your free to do so of course. >> But I don't think we will incorporate it into the standard distribution. >> >> Regards >> Vampire >> >> John Smith schrieb: >> >> I haven't heard anything for a few days - is my solution acceptable? > > [Snipped] > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > > |
|
From: Justin F. <jyf...@gm...> - 2011-07-13 11:58:02
|
Hello all Sorry for dragging up such an old discussion, but I have been meaning to reply to this for some time. I found that I could pin jEdit to the taskbar by creating a shortcut that basically just executes "javaw.exe -jar jedit.jar" (of course also with all the paths and switches/arguments) and it works without problems. I had to manually set the icon on the shortcut, but after that it will pin with the right jEdit icon and has the right icon and name in the program list. Perhaps not a work-around that can be distributed, but it has been a functional solution for me. :-) Justin On Mon, Jun 13, 2011 at 11:07 PM, Vampire <Va...@je...> wrote: > Ok, I've spend some days now to actually evaluate WinRun4j. > Of course I like the possibility to "correctly" pin jEdit to the > taskbar, meaning not having a different icon for a running instance, > and the process being named jedit.exe. > But actually it doesn't work really smooth. > It cannot be put into the build process properly as it must be > assembled on a 64bit Windows system to also assemble the 64bit > executables that are necessary for 64bit JVMs with WinRun4J. > It also doesn't reliably start the program in question. > In my tests the jEdit GUI was garbage most of the time. > Also the executable attributes like version, name and description > cannot be set correctly and thus in file assignment dialogs and so on > jEdit is not shown nicely. > The embedded icons are not shown reliably and this has nothing to do > with any caches as I moved and copied around the files to circumvent > eventual caches, ... > > All in all I have to say that WinRun4J is a nice idea, but currently > too crappy for me using it in production environment. > > Regards > Vampire > > 2011/4/18 Rowan Collins <row...@gm...>: >> Hi Vampire, >> >> Just wondering on what basis you have decided the project is not "stable": >> is it just because it has a version number less than 1.0? >> >> Given the large number of posts on this mailing list about correct >> versioning schemes, I'm surprised you don't realise that version numbers >> mean different things to different people - and in particular, hackers are >> scared of 1.0 >> >> I don't know anything about the project in question, but looking at their >> website, I see that there have been 24 releases over 4 years (unless I'm >> much mistaken, 2007-05-07 is not "more than 5 years" ago...) I see no >> summary or FAQ to tell me how stable they consider their latest release, so >> wouldn't want to jump to conclusions. >> >> Maybe I'm being harsh, and you have actually looked into this, but since you >> admitted not looking into features, it seemed like "0.4.1 < 1.0.0" was the >> only evidence used to condemn its inclusion. >> >> Regards, >> Rowan Collins >> [IMSoP] >> >> >> >> On 09/04/2011 01:11, Vampire wrote: >> >> The problem is not about any features. >> I didn't look into the features, maybe there is a problem too. >> But the problem is that WinRun4J has not released any stable version yet >> since they exist over the last couple of years. >> jEdit in contrast is a pretty stable program. >> If jEdit now uses and depends on WinRun4J, then jEdit itself is not to be >> considered stable anymore. >> You know, a chain is only as strong as its weakest link >> >> John Smith schrieb: >> >> Hi: >> >> I'm not sure I understand the concern - if it does what is needed, then >> isn't that good enough? Or is there some required feature that is present >> in Launch4J? If so, I can look into making some changes to it. >> >> I admit that 5 years is a long time, and perhaps it's a dead project, but it >> seems like jEdit only needs a very basic launcher. >> >> >> On 8 April 2011 09:17, Vampire <Va...@je...> wrote: >>> >>> Hi John, >>> >>> unfortunately it isn't. >>> I was aware of WinRun4J alread. >>> But they are at version 0.4.2 which means they didn't get it managed >>> to release even one version they think theirselves is stable in more than >>> 5 years. >>> If you want to use that EXE for yourself, your free to do so of course. >>> But I don't think we will incorporate it into the standard distribution. >>> >>> Regards >>> Vampire >>> >>> John Smith schrieb: >>> >>> I haven't heard anything for a few days - is my solution acceptable? >> >> [Snipped] >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > -- > ----------------------------------------------- > jEdit Users' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-users > |
